Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
i have a lot of interest in programming, particularly creating gui programs. i have done some searches on the web and know that i need some libraries(qt for example) in order to create the gui interface, which i have no problem with. my question is that once i have created the program(lets say in c++ and qt) and compiled it, will it be able to run in a computer that does not have the qt library installed? and in case it wont, how can i create a gui program that does not need any special libraries to render the interface?
Qt is really good, but remember that it's not allowed to deploy applications using the libraries as static, it's paid. ("Static linking is not subject to the new LGPL-licensing, thus you'll have to buy a commercial license if don't want to release your own code under the GPL." - here) Qt allows only, for free (under license), shared/dynamic linking.
wxWidgets allows static linking for free. Maybe GTKmm as well.
For Qt you need either to deploy static apps (for which you need to rebuild your Qt for static builds, and that is not a trivial task usually) or to supply all needed Qt/compiler libraries together with your application.
Anyway you can start here or here (the latter is a quick guide for deploying dynamic apps on different platforms).
Also, if you don't need cross-compiling to different platforms - you'd be good with using native platform-dependant API (such as WinAPI for Windows f.e.) that usually compiles under most compilers on that platform cause all the libraries needed are already supplied with the platform.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know that win32 API is written in C language and also why Qt is portable?
Could someone explain this to me?
Because WinAPI was not designed to be portable as it targets only the Windows OS while the QT framework targets multiple OS-es. The fact that WinAPI was written in C does not make a difference.
The windows API is portable in the sense of being processor agnostic (indeed, it has run on many non-Intel processors over the years). It is not portable in the sense of being OS agnostic; although even there Microsoft's is not the only implementation of the API. The wine project has done a credible job of re-implementing the API for other platforms, to the point that windows binaries will run, at least on processors that match the binary.
The fact that the WinAPI is aimed at C makes no difference.
Just because the language is cross platform it does not mean the library (especially in the case of those like WinAPI which are not in the standard library) are the same.
It's just a library that interacts with the video card/processor to make a GUI on a very low level. At this point it is so low level the process depends more on memory locations or processor specific operations. IE saying that certain memory locations (specific to the OS) will reference a pixel on a screen ect.
The Win32API has been built so that it only "knows" the tasks for computers with Windows OS, libraries like QT, once again are still not truly "cross-platform" they have just been built to include all the relevant operations needed for each OS it covers.
Why is a rather open question; but here's my take on it:
Win32 API is produced by microsoft; which has commercial reasons for not being portable.
QT is open source; which was created with the sole intention to be portable.
Bonus:
X11 is open source; which was created with the idea that the machine displaying the images might not be the machine running the program that wants the window. Which makes it inherently non-portable to other APIs that don't (eg windows)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm currently programming a small library with abstract classes. Its a library that offers simple GUI creation classes, like widget, main_window etc.
My goal is to code an application using interfaces and factory functions to creates actual objects. I use cmake for my project (for info but doesnt really matters). I'd like to include in my lib the abstract classes (easy) and different engine (like qt5_engine, gtk_engine, ...).
The client(my application) using the lib can see only the abstract interfaces, and factory functions(methods, lambdas, builder classes??). When building the lib, I choose which engine to build (only one) to get libmy_lib.so. My application will use libmy_lib.so, no matter if its compiled with my qt5_engine or gtk_engine (staticly linked into my_lib for each engine)
So that finally, I can simply overwrite libmy_lib.so compiled with a different engine to change the GUI used by my application. But I also like to know of a clean way to implement such lib with different engine, to get a clean code, the 'best pratices' for lib programming in other word.
I kinda found the way to ask it, and so, the way to search for it >< I accepted an answer which is the part for the 'change le lib file to change the GUI' but if you have references to library coding the clean way, the modern way, that would be awesome...
Thx
Look up "ABI compatibility". The Qt/KDE projects have a good guide about that:
https://wiki.qt.io/Qt-Version-Compatibility
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++
The extreme version of that would be the "Hourglass Interface" pattern, where the binary interface of the library is pure C, but there's an inlined C++ API above it and a C++ implementation below:
https://www.youtube.com/watch?v=PVYdHDm0q6Y
EDIT: Just wanted to add a clarification: Where these guides talk about compatibility between different versions, your libraries would have to adhere to the same restrictions for different backends.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Sorry if this sounds a bit newish. I am writing a cross-platform application to learn C++, which, if it turns out to work well, could help people. I would like it to be able to be used in two ways: by the designed GUI (may be using QT), or by command line for expert users who want to go beyond.
I would like to know how the communication between GUI application and the core should be made, since this is going to be open source and I want the code to be nice and clean.
Is there any commonly accepted way to do this?
There are a few approaches you could follow.
First write the CLI, then write the GUI as a standalone program that spawns the CLI version for all processing (via the system(), popen(), fork(), g_spawn(), CreateProcess() or similar calls). This may be a little more tedious than writing a library, but works well if you have already written the CLI, or in cases such as batch processing where the GUI is just a fancy form where you choose the parameters.
Split the application not into two, but three parts: library, GUI and CLI. The library would contain all the shared logic between GUI and CLI, such as handling input formats, editing operations, and so on. The GUI part would implement the graphical interface using the functions from the library, and the CLI would implement the command-line interface using the same library.
Make the GUI application accept command-line parameters, and avoid initializing the widget library if the passed parameters indicate that it is invoked in CLI mode. This is OK for a primarily graphical application such as a bitmap editor or a programming IDE that needs to expose some operations for scripting. Note that some extra hacking is required to make this work on Windows, see this answer. Also note that this will make it harder to run the app on servers that don't have a windowing system, since it will still have GUI libraries linked in.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am new to programming. I'd like to learn a new application programming language. I Googled and found the old MFC framework. I would like to ask: Is MFC still valuable?
I want to develop desktop applications. If not what should I choose to learn in depth?
If you want to develop desktop applications, then I'd recommend to avoid MFC and study Qt instead. Qt is quite powerful/flexible and using it won't lock you into single platform/OS.
First, you must have clear the platform where you want your applications to run; Windows? Linux? both?
In case you just care about Windows, MFC can be a good option if you want to do C++ native programming, which I suppose it's your case (otherwise, C# and .net could be a better way to start programming...)
MFC is a mature framework and once you get the basics, it will be as easy (or difficult) to use as any other library (e.g. Qt or TCL/Tk). IMHO.
I recently tried to use to MFC for a small client application.
After struggling for two days with trivial things (like how to change the font on a button!!) I gave up.
I gave a quick look at Qt and wxWidgets but (after having lost another couple of days), they seemed too compex for my task. Qt is probably the right way to go if you have time and/or the constraint to stay with a C++ framework.
It was not the case for me, so I decided to try Tcl/Tk to see what it had for me.
In its "tclkit/starkit" incarnation it allows you to create standalone GUI application with native look and feel. C/C++ code can be placed in a DLL that is embedded in the exe itself (no DLL hell, thanks!) and can be called directly from the Tcl script.
In two days work I almost finished the entire GUI with all the user interactions (enable/disable menaingful button, load listbox depending on other fields, ...) that would have taken weeks in MFC.
Tcl/Tk has its learning curve and may result unfamiliar to some but it repays many many times in productivity. Also, there are a lot of books, tutorials, examples, etc to learn from.
I would suggest you to give a look to see if it suits your need before going elswhere.
If you are happy with the document-view (MDI or SDI) nature of MFC go for it. It's great if your worried about distribution becuase you dont need a hefty framework, just a couple of DLLs. Don't expect rapid development without considerable background knowledge.
If you're interested in more modern C++ frameworks for Windows, consider using WTL and ATL instead of MFC.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have had numerous bad experiences with GUI library
so I would like to know how to create a window from scratch in c++
I am not talking about win32, what I mean is basically create it myself without any external library
is there any way to maybe use a picture or something to create a window
yes I know how hard this will be.
also I read somewhere that library could be made for c++ in assembly
is there a way to create a custom gui in assembly or c++
EDIT:
I am aiming at just windows
PS: another reason I want to learn how to do this is because
I might want to actually create an OS. so I would want GUI with that...
In order to create a window you'll need to interface with whatever windowing system is currently present on your operating system. This will either require system calls if the window manager runs in kernel space (as is the case in Windows) or some sort of interprocess communication for user space window managers (like X). To create the window from scratch, you'll need to read up on how these window managers work and what protocols they use. In the case of X, it shouldn't be too hard to find resources on how the protocol works. In the case of Windows, your only option might be to use the API, since the internals of the window manager are proprietary.
You could try perusing the source code to MenuetOS - I believe it's written entirely in assembly and it has a GUI. Of course, this won't work if you're trying to write a program that runs on Windows, Linux, etc. But if you want to avoid all external libraries, including interfacing with Windows, you will have to run on the bare metal.
If you are crazy enough to do this thing in assembly go ahead and install masm32 , it can do basic GUIs like windows/messageboxes etc.
You create a window "from scratch" on windows, by calling the "CreateWindowEx" Win32 API.