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.
Related
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 3 years ago.
Improve this question
After reading some posts online, even though they explain it using non-coding way, I still feel unclear about this. They explain it using some examples in our real life.
Could you please explain it in coding way?
What is framework?
My understand is that it is pretty much like class template in c++.
template <typename T> class Reader {
// code details
}
So, if we want the reader to read newspaper, we instantiate Reader<NewsPaper> or Reader<ScaryBook>
Am I right? Or what's wrong if understanding framework this way?
Thank you!
As for me term "framework" doesn't suit C/C++ world well. Traditionally external modules in these languages are named "libraries" or "libs" (this naming is used in *nix systems as well when downloading them from web repository). Even though there might be some different interpretation for this terms, they are generally about the same thing (especially for C/C++ applications).
External library is a piece of code which performs some functionality. When dealing with big libraries (like one for creating, networking, image processing, multi-threading etc.) programmer has to follow some workflow proposed by it. You may think of library as a "black box". It provides you interface (rules how to use it: input and output params, error codes etc.) but you don't know what is inside and generally don't need it.
Depending on solved problem library may be (or not) extensible. Library for reading various audio formats may not provide way to create readers for new audio formats but networking library should provide functionality to create user-defined networking protocols.
And template is a variadic piece of code. One backbone code which suits different datatypes. It's a powerful tool both for applications design and performance (which is commonly used in libraries as well for that reasons).
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 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.
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 7 years ago.
Improve this question
I was looking at Qt and came to wondering, what is the most popular general purpose C++ framework, and what are some pros and cons of it?
The STL and Boost are both pretty popular, and they're pretty much the epitome of "general purpose".
Qt is very popular. It's available under open-source (LGPL) and commercial licenses, has fully-featured core and GUI class libraries and an integrated IDE and build system. It's also cross-platform.
It's under very active development and has a new declarative UI library (QtQuick including QML) due in the next release (4.7).
Definitely worth checking out for new projects.
For Windows-only work MFC is still worth a look. It's recently been updated.
The question as it stands is probably unanswerable; you'll probably end up with a list of people's interpretation of "framework" with no real way for distinguishing them.
Perhaps we need a definition of framework? I suggest it is a library that in some way determines the architecture of an entire application. However that is perhaps a definition of "Application Framework", but if you mean the term more broadly, then the question is probably too broad. This definition however makes say Qt a framework, while Boost remains just a library. That makes Boost no more or less useful, so I really don't understand what you are trying to discover from the question.
Here's a list of UI related libraries that might be considered "frameworks":
MFC
.Net
WxWidgets
Qt
KDE
GNOME
TurboVision ;-)
The most notable distinguishing feature is that some of them are cross-platform, and some are platform specific. Gnome is perhaps distinguished by having a C API (GTK+). .Net supports multiple languages, but requires C++/CLI rather than ISO C++ (but that is no worse than Qt's pre-processor IMO). MFC is a bit long in the tooth and not supported by free or third-party tools. TurboVision is antique and included for my amusement and geek nostalgia.
I know this post is old but I found it very useful.
I would like to add PoCo (POrtable COmponents) to the list
I used it for seleral projects and includes a consistent and well designed framework for:
XML
Multi threading
Networking
Cryptography
General purposes
It is also portable (I used it on Windows and Unix).
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 2 years ago.
Improve this question
I use wxWidgets to create test tools at work. I have always created the GUI by creating the widgets in code. I haven't tried any of the tools available that help to do this. How do other users of wxWidgets typically create their interface? If you use a tool, which tool do you use? If you use a tool, what advantages and disadvantages do you think there are for using that tool?
I've used wxFormBuilder for two reasons:
It's cross-platform and I needed something that would work on Linux.
I'm new to wxWidgets and I didn't want to spend lots of time futzing about with building the GUI.
I think it works quite well, and being familiar with similar GUI building tools (Borland C++ Builder, Jigloo for Java, Delphi) I found it easy to use.
If you stick with the paradigm of using wxFormBuilder to generate base classes, and then you make a class that inherits to layer your application specific logic on top, absolutely not hand-editing the C++ code wxFormBuilder generates, then it works well and you can easily update and modify your GUIs in wxFormBuilder again (and again...).
Advantages:
Can generate your base GUIs quite quickly, in a visual manner, without having to constantly look up the documentation.
Don't have to do as many code/compile/run cycles just to make sure your GUI is looking like what you expected.
The base class/derived class paradigm can make a reasonably clean separation of your GUI and business logic code.
Potential Disadvantages
Disclaimer: I've only used wxWidgets to create very simple, straight-forward GUIs, so haven't really pushed the tool to any limits.
Potentially the base class/derived class paradigm could sometimes get in your way if you are doing something too sophisticated with your GUI (OTOH that could indicate that you may need to re-think your approach.)
I had a situation where I needed a menu item when compiled for one operating system, but not when compiled for another. There is no logic in wxFormBuilder to support this. I ended up taking the short-cut of always creating the menu item and then having my derived class make it invisible if it was the wrong OS (not ideal.)
That's about it, I think.
What I find is that I often build the first cut at a GUI using a tool, and when it seems to be converging on the "final" form, I start to recode/refactor by hand.
Some of this depends on the tools, though, too. I'm not a big wxWidget fan.
You know, it depends.
E.g. if I need some standard behaviour, I usually use DialogBlocks for GUI because it is the fastest way.
If I need custom behaviour (e.g. my current project is cross-platform media manager whose GUI supports skins) then I do all GUI-relates things in code.
As for custom controls:
If a control does some project-specific thing, then I create it in DialogBlocks using the same project file (with other forms and dialogs used in this project)
If my control should be reusable (general-purpose control) then I create a separate project for it and create a keleton in DialogBlocks - add empty event handlers and class variables if possible, then write logic manually in Visual Studio.
That's it :)
You might want to look into using XRC/XRS files.
Though I must admit I haven't bothered to do so myself. Just generating static GUI code using wxFormBuilder (which has XRC support, btw) has been enough for all my (small-scale) GUI designs.