is there any way to create a GUI in Monodevelop using the c++ language? i know about the built in Stetic development tool , but it seems to only work with c#, and i need it for a c++ project (for my class).
C++ has many different toolkits for handling GUIs, you need to specify what you want to achieve.
You can use monodevelop and Stetic tool to build a GTK interface for example, then implement your logic in C++ (which GTK has, of course, support for). I personally never attempted something like that, so you might wanna check the tooling and support, but it should be theoretically possible.
Worth noting is, XAML is basically cross platform in the context of Universal Windows Applications, so you might wanna check that out first. Look for Xamarin and try to stick to current information, the platform is a big technological shift for Microsoft.
This is outdated, but gives you an idea
Using C++/Qt and QML with QT Designer (as suggested by #Joachim Pileborg) is one of the best paths to undertake for a stable, cross platform, native looking GUI toolkit.
Related
I have a fully-working audio/video application which is entirely written in Objective-C (with bits of C/C++ and GLSL).
I now need to port it to Windows and I'm wondering what my best options are. I'd like to stay in the C/C++ domain so Java is not an option.
I know that this will be a lot of work but I also want this to be good (attention to detail is very important to me, I subclassed many UI elements to suit my needs).
Currently, I think that I could either port the whole app to C++ and use Qt for the whole UI (I did some small projects with that and found it mostly ok) or I could port the application core and write two different UIs for Windows and Mac (the Mac UI is already there of course).
Has anyone of you done what I'm trying to do and can give any insight? What's the best approach and why?
I have almost zero knowledge of Objective-C and macOS UI, but on Windows I think the best C++ OO tiny and efficient wrapper around native C Win32 APIs is WTL, based on ATL.
There's a quality series on WTL on CodeProject.
In the realm of Windows-specific C++ frameworks/libraries, you may consider MFC as well (which offers good integration with Visual Studio IDE), but honestly I prefer WTL: it's kind of more lightweight than MFC.
In addition, there's the cross-platform Qt alternative you already cited in your question.
Is there any way to build graphical interfaces in the same rapid and easy way we could do in Visual Studio, but without .NET Framework? I'm looking to native Windows GUIs, so using Qt with Qt Creator is not an option (and it doesn't need to be cross-platform). Something with the Windows API using C++ would be great (not Delphi).
I mean, applications like WinSCP really have its GUIs written entirely by hand?
Given:
You don't want to use Qt
You want to use Win API
The natural option is MFC. It's basically quite a thin wrapper around the Win32 UI API, but VS has an MFC UI designer that will save you a lot of work (no need to manually set the co-ordinates of controls etc.).
My vote is still on Qt.
I suspect OP is really confusing "Native" with "deployable in a single binary". You can achieve this also with Qt by statically linking Qt dependencies. Contrary to popular belief, the LGPL does not prohibit this either.
Now if OP is looking for "deployable in a single super small binary" utorrent style, the answer would differ. A discussion around small binaries seems a good place to look. I would say there is a price to pay in increased development time though.
But I can't agree on Qt not being as native as say MFC.
Another excellent option is C++Builder with the VCL. This is very similar to WinForms (whose design it clearly inspired) and much more productive than MFC in my opinion.
As both Qt and MFC are wrappers around the native OS functions for managing windows and other OS utilities (that use Win32 API under the hood and look completely native) there is really no reason to consider the use of MFC over Qt, as it is not more native than Qt. Either your definition of "native" is broken or you haven't told us the whole story.
But there are a thousand reasons for considering Qt over MFC, as the latter is a complete pain to use, whereas the former is a cleanly designed, easy to use and still highly flexible library (that strives for nativity by any means possible).
The only way you might see MFC as more native is that it comes from Microsoft (the same company that developed Windows). But that doesn't make it more native. It's still a third party library. This third party worked for the same company as the party developing the Win32 API, but that doesn't make it specifically more tied to the Win32 API, as both were developed independently (and surely by different people).
Do Qt apps look and feel native under Windows?
You could also take a look at wxWidgets.
In addition to MFC, you might want to look into the Windows Template Library.
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
It has been a few years since I did any development for PCs (I usually do embedded software).
At that time I was highly proficient with (Borland, now CodeGear) C++ Builder. Time has moved on, C++ Builder has become extremely expensive and there are alternatives (MSVC studio, NetBeans, QtCreator, maybe even Eclipse with the right plugins). Others?
Three things concern me (in no particular order), ease of use, additional GUI components and cross-platformness.
Ease of use - I want an IDE which helps, not hinders me. Good debugger, refactoring, jump to variable declaration, usage, that sort of thing ..
GUI components - when using C++ Builder I was impressed by how easy it was to develop additional VCL components and how many were available, often for free. Thus if I wanted a standard string grid where the cells also could contain pictures, checkboxes, etc, I could probably find one, or roll my own.
I am not sure what the current state of play is with respect to add-on components. Do other systems have anything like http://www.tmssoftware.com/site/ ?
Cross-platform - I personally use Linux for everything, but realistically, the majority of my users have Windows installations. So, cross-platform is "nice to have", "all other things being equal".
Now I have to pick a solution and stick with it for the next few years. Which one, given my points above (cost plays a role, but is not make/break)?
Thanks in advance for your help.
I have used both C++ Builder and Visual Studio.
Over the years I have always preferred C++ Builder over V.S.
Builder and VCL just feels much better designed than Microsoft's products.
(Even the Borland library source code just looks cleaner than anything
that comes out of Microsoft).
The integrated debugger in Builder is truely integrated and quite intuitive to use.
I find Builder compiles much faster than Visual Studio.
Builder 5 had a problem that made it unnecessarily slow,
but at the time it was still faster than VC++
and the latest Builder versions have faster compile times.
Accellerators such as TwineCompile make Builder even faster.
I've never tried to create custom C++ controls for Visual Studio,
but it is fairly easy to do in Builder.
Last year, CodeGear released a free version of TurboExplorer
(I haven't used it myself) which includes the IDE
and RAD (although limited) http://www.turboexplorer.com/
TurboExplorer can be used for commercial apps.
I have not been happy with Java based IDE's where are always slow.
I.e. SunStudio12 which is good (and free) but the UI is slow response.
I use Code:Blocks on Linux which has reasonable usability,
but haven't done any RAD work with it.
I never used C++ Builder but used to be a big fan/user of delphi. I normally work on server apps in c++, with some java. Reciently I started writing some small productivity apps for myself originally I used java, but then moved to Qt.
Now I love it. The library feels well designed just like vcl did in delphi. The signals/slots mechanism is great, I am still surprised how often I don't have to write code to wire up a dialog box. Using qt is easy and the code you write is very easy to read and create. I haven't yet had to write my own widgets, I think qt's model/view architecture splits the roles very well making the stock widgets very powerful. For example when using a QTableView most display and editing functions can be provided by the ItemModel, more powerful control is provided by an ItemDelegate. I have found these easier to reuse than writing custom widgets although it seems easy enough from looking at the documentation.
Qt creator is basic but does 95% of what I require, integrated project, gui designer, code, debug and help. Has support for CMake as well as qmake. It doesn't have advanced features like refactoring, but the intelli sense better than VS2005. However the next version of KDevelop looks very promising and will include these. You could also use eclipse if you wanted these features, or move between eclipse and qt creator as required. But I am very happy with qt creator.
On the cross platform issue, I develop my apps on Linux at home and tend to use them on windows in work. So far everything that works on linux works just work windows and looks like it was written for it too.
The strength of C++ Builder (and also Delphi) is the VCL GUI framework, it is easy to work with, and delivers true RAD development. There are a lot of alternatives to VCL which all have their strengths and weaknesses. The strength of VCL is the close ties with C++Builder/Delphi which makes it work very well with that combination. The downside is that it is propitiatory software, which means that you are unlikely to port your code to other IDE's or platforms without official support from Codegear/Embarcadero.
There is however some free alternatives out there, one of the more interesting being the Lazarus IDE. The Lazarus IDE is an IDE for the Free Pascal language, this is very similar to that of Delphi, I must admit that I am not a Delphi guy myself, so I am unable to go into too much detail about this. Lazarus have a GUI framework much like VCL called LCL. From the brief looks I've had on it, it looks very similar. There are several good things about the Lazarus/Freepascal package especially for your case. It is free, it can compile and build for both windows, linux, and mac, it has 64 bit support. Further more the compiler seems more modern than the Delphi one.
Lazarus running on Windows 7
Lazarus running on Linux (GTK2)
Lazarus running on Mac OSX
More screenshots can be found here: http://wiki.lazarus.freepascal.org/Screenshots
The problem with Delphi/C++Builder is that the VCL is not currently crossplatform capable. Although this is planned for future versions (as far as I recall) it is not yet implemented. Having noted that, there are some considerations as to whether the C++Builder will continue to be maintained or not, in here there is some comments on this: here.
Qt has been mentioned and it is indeed a very strong GUI framework and the Qt creator is a fine tool, personally though I like to have a very close bond between the IDE and the GUI framework like it is the case with the VCL, but that is very dependent on the developer.
Edit: Just a thought I had, when comparing C++Builder to other RAD IDE's it is easy to include IDE's for the .NET languages and Java. These use languages created for this purpose. C++ used in C++ Builder does, although in Borlands version slightly modified, not. This does raise an interesting question, is using C++ for RAD applications necessary and justifiable? Why not use a tool (language) that is written for the purpose. I am aware that C++ Builder is written for RAD development, but the language behind it was not designed for this purpose. If your need is truly rapidly developed applications, I would consider looking for other languages, but if you dependent on C++ for whatever reason, could be 3rd party libraries etc. Then C++ Builder is in the C++ world an excellent RAD development platform.
Short answer is NetBeans. It is cross platform, it is easy to use, although it is made-in-java but still it is fast.
PS: If you also do or intend-to-do programming in java, it will be convenient to use/learn this one IDE for both.
You can also use wxForms for C++ Builder and use wxWidgets to create cross platform applications. It works with the existing C++Builder IDE and make use of the same form designer.
On my side job as programmer, I am to write a program in C++ to convert audio files from/to various formats. Probably, this will involve building a simple GUI.
Will it be a great effort to build seperate GUIs for Mac and Windows using Cocoa and WinForms instead of a cross-platform toolkit like Qt or GTK? (I will have to maintain a seperate Windows-version and Mac-Version anyway)
The GUI will probably be very simple and only need very basic functionality.
I always felt that native GUIs feel far more intuitive than its cross-platform brethren...
If you have the expertise, use native frontends, it'll effectively double the job you have to do for UI but from my experience non-native UI is a little bit clunkier than their native counterparts.
Have you looked at wxWidgets? Cross platform native controls.
I would agree that if possible, native front-ends are the way to go. I've not used wxWidgets recently, and I've heard it's come a long way, but back when it was wxWindows, we built an app with it that was spec'd to be built in X/Motif. When we finished the effort and delivered it, the customer said it did not look enough like X/Motif, and we had to re-work the entire UI at our expense... Joel Spolsky wrote a good article on this, but I can't remember the title. What he did say, IIRC, was the problem with Java and some other cross-platform UI was that "your dog barks at my app" - it's the little inconsistencies that annoy folks.
Cross-platform toolkits, more or less, all make the incorrect assumption that the difference between platforms is a matter of button placement and widget styling. In some cases you can get away with this - a Qt app will feel fairly native on both Windows (where UI conventions are very lax) and on Linux, particularly a KDE environment. In general, you can move between Linux and Windows relatively easily; conventions are similar, and the Windows community is lax about them.
Mac is the hard one. Its UI is built around an entirely different paradigm than either Windows or most Linux environments.
But in general, in a native app it's easier to speak the native language of the platform in more ways than just widget style.
Yes.
But seriously, it depends on your goals. I agree that the native UI libraries, with a bunch of effort put into them, will give vastly better results, but for lots of apps, a very basic UI is sufficient and a lot less effort if you take one of the existing cross platform frameworks.
Maybe starting with the CLI and getting functionality working makes the most sense for an audio conversion application.
I'm going to write my own cross platform application GUI layer for this soon.
Depending on the complexity of your application this can be a fraction of what is required for QT, GTK or FOX.
Reason is that we see a tendency that the platform vendors (Apple first) tries to design there system so that it looks unique. This makes it much harder for QT, GTK, FOX and other platform tools to constantly keep in sync with the latest widgets.
When the underlaying technique becomes more and more the same the OS vendors have no option then branding on look and feel of the platform.
wxWidgets used standard c++ syntax and preprocessor thus make you easily alter from plain C or C++. And will produce very native look where is appear, be it on GTK, X11, MS-Windows or Mac.
It's mature since 20yrs of 1rst release, has complete documentation with easy navigating, and supported by large community arround the world.
Coding in your favorite IDE or use prominent Eclipse-IDE and wxFormBuilder as GUI designer. Build wx library and IDE/Toolchain setup could be found on this link: http://yasriady.blogspot.co.id/2016/01/raspberry-pi-toolchain.html
Develop your application in Linux desktop and also provided compiler for Raspberry Pi2 (target application tested work smootly on Raspbian Jessie) ............