I'm writing a UI for my program using opengl with SDL in a combination of Lua and C++
What I need now is some library that will allow me to call a function that presents the user with a file select dialog for opening/saving a file. But if the OS offers native functionality for such a dialog, then I want to use that dialog (eg Window's GetOpenFileName).
The only platforms I need to support are Windows and Linux, but I want to be able to still use most of the SDL & openGL code I've already written.
What options are available?
tinyfiledialogs offers many modal dialogs and popup notifications (both for graphic and console modes). It is a cross-platform C file (with a header) to add to your C or C++ project. It aims to be extremely easy to use, has no init, no main loop, and no external dependencies. It is used by hundreds of projects on GitHub and of course, I am the author. Get it here: http://tinyfiledialogs.sourceforge.net
Usage example:
char const * selection = tinyfd_openFileDialog( // there is also a wchar_t version
"Select file", // title
"C:\\", // optional initial directory
2, // number of filter patterns
lFilterPatterns, // char const * lFilterPatterns[2] = { "*.txt", "*.jpg" };
NULL, // optional filter description
0 // forbid multiple selections
);
You should take a good look at Native File Dialog. It is a small, portable C library that lets you use load and save dialogs in a cross platform manner without linking huge dependencies like qt or wxWidgets.
I am the author, and I use it with SDL2 and OpenGL on Linux, Mac and Windows.
https://github.com/mlabbe/nativefiledialog
In my opinion, wxWidgets is the open source, battle tested, mature, cross platform, cross language, free, open source, GUI library. Beside wxWidgets, there are also many other such cross platform libraries, such as:
Tk
FLTK
FOX
XUL
AbiWord's cross platform layer
... and more.
You will most likely find you're looking for in the AbiWord source code. Look for "FileOpen" inside the src directory:
./af/xap/cocoa/xap_CocoaDlg_FileOpenSaveAs.cpp
./af/xap/cocoa/xap_CocoaDlg_FileOpenSaveAs.h
./af/xap/cocoa/xap_CocoaFileOpen_Views.nib
./af/xap/cocoa/xap_CocoaFileOpen_Views.nib/classes.nib
./af/xap/cocoa/xap_CocoaFileOpen_Views.nib/info.nib
./af/xap/cocoa/xap_CocoaFileOpen_Views.nib/keyedobjects.nib
./af/xap/gtk/xap_UnixDlg_FileOpenSaveAs.cpp
./af/xap/gtk/xap_UnixDlg_FileOpenSaveAs.h
./af/xap/win/xap_Win32Dlg_FileOpenSaveAs.cpp
./af/xap/win/xap_Win32Dlg_FileOpenSaveAs.h
./af/xap/xp/xap_Dlg_FileOpenSaveAs.cpp
./af/xap/xp/xap_Dlg_FileOpenSaveAs.h
The Windows version does indeed use GetOpenFileName().
Of course, as Andre points out while downvoting a valid alternative answer, there's also Qt, as you already know. Refer to raj's answer for a link.
https://doc.qt.io/qt-5/qfiledialog.html provides a good abstraction of os file open services
I have used another good library:
https://github.com/samhocevar/portable-file-dialogs
It is a single header library with support for Linux / Mac / Windows
Related
Im a newbie and want to know if this is possible so that it may help in my project which is only in c++. This is something similar to "uigetfile" in matlab.I use Ubuntu.
Thanks in advance.
You will need to add windowing capability to your program. The standard C++ language has no facilities for dialog boxes.
Windowing is platform specific. You may find windowing frameworks that are cross-platform.
Dialog box creation is either OS dependent or windowing framework dependent.
You didn't specify in your post the OS you are using.
Graphical User Interfaces (GUI or UI) are very complex systems that depends on many layers of hardware and software:
The hardware, especially the graphic card help for drawing and showing the result on screen.
Driver: To access the Graphic card. This is already platform-dependent.
Operating system: Give you facilities to user the graphic card and usually a library for drawing your GUI.
This mean, there is not a standard way to make a GUI, and that C++ stay outside of the mess.
However, some libraries abstract the different systems and provide single API for creating GUI, this obviously relay on the library having implemented the specific platform details, so it will never be 100% cross-platform.
Examples of GUI libraries are:
QT (e.g. used for KDE)
GDK (e.g. used for GNOME / UNITY)
wxWidgets
...
Is there any way to have a simple edit box in plain X11 C or C++ code?
By "plain X11 C or C++ code" I mean creating the control on a XCreateSimpleWindow created window as the CreateWindow("edit"..) equivalent in Win32 API.
If not, what are my options to have a simple edit box with the minimum amount of dependencies (i.e. no Qt please) for a simple edit box input dialog?
Plain X11 doesn't have such functionality - It is a low-level windowing toolkit (opening and maintaining windows, receiving input events, drawing to windows).
In case you are prepared to write such an edit window from the available primitives, you are fine. If not, you need to use some toolkit that does it for you. The simplest and most lightweight one providing such functions would probably be Athena widgets (in case you are not particularily choosy about look and feel).
X11 is a very low level protocol. It provides the ability to create individual windows, draw on them, and receive individual input events, and nothing more. That's it.
The job of providing high level user interface, like edit boxes, is for higher level toolkits, like Qt or Gtk. Those are the most common toolkits. There are a few less-popular ones too.
But the bottom line is that there are no "edit controls" of any kind, that you get with Xlib, the library you're using to talk X11 protocol. If the only dependency you want is Xlib, then it's up to you to actually implement the edit control, using your own code. If you don't want to use any common font handling libraries, like fontconfig and freetype, you will have to write the code to enumerate the X server's built-in fonts, handle keyboard input, and draw your edit control. Just the job of translating the somewhat obscure keyboard encodings used in X11 into something usable, like UTF-8 or unicode, will take a few hundreds of lines of code.
So the answer here is: use Qt or Gtk.
As low level alternative for X widgets you can use Xaw library, or Motif library or Xforms library.
I would like to write a console app with text UI in D. I looked at curses, but it seems that it works only on unix. Are there any cross-patform alternatives?
My terminal.d could be used as a foundation for a TUI library.
https://github.com/adamdruppe/arsd/blob/master/terminal.d
It has no required dependencies, so you can simply download that one file and start building with dmd yourfile.d terminal.d. Here's an example program getting input: http://arsdnet.net/dcode/book/chapter_12/07/input.d
You can also use terminal.moveTo(x, y); terminal.color(Color.green, Color.black); terminal.writef("something"); terminal.flush(); and such to move and draw.
Look for version(Demo) in terminal.d itself for a main which handles all kinds of input events, including mouse events.
While terminal.d mostly offers lower-level functions (its main high level function is terminal.getline, great for line based apps but not TUIs), it should give all the foundation needed to write a little text widget library.
and I think someone might have done that once but I don't recall where.
terminal.d works on Windows and Posix systems, for the most common terminals like xterm. ncurses is more comprehensive and probably has fewer bugs on more obscure targets but terminal.d, being a single file, is easier to build.
That was true long ago. However, ncurses is known to work nicely on Windows as well. The easiest way to build it on Windows is inside the MSYS2 shell. There is really no other cross-platform alternative to Curses (find out why they named the project "curses" and you will find why there is no good alternative).
I need to write an application that will be visually indistinguishable from something written natively for Windows XP/Vista/7 using whatever comes by default with the most modern Visual Studio. But I'm developing using MinGW and Vim (in C++).
In particular, I want the following controls to be native on the above three versions of Windows: form chrome, buttons, check boxes, menus, combo boxes, progress bars, scrollbars, rich text boxes. This will be enough for me.
I know that if you load GdiPlus and other things like riched32.dll as needed, and use Windows API to instantiate controls, then the OS will substitute its version of GdiPlus or other library, so it will look like XP style controls on XP, Vista on Vista, etc.
But I don't want to use plain Windows API, because even retrieving the default font takes half a page of code, and similar stories whatever I want to do. So I'd like to use a toolkit.
wxWidgets, Qt, GTK+, FLTK seem like the most widely used. But they are all cross-platform. I've used cross-platform applications, and many of them have foreign GUI controls (I call them widgets). So my question is: which of these toolkits can be made to produce true native-looking UI controls listed above, appearing correctly on the three versions of MSWin listed above?
I've typed each of them +" windows" into Google Images, but it's hard to tell, except that FLTK probably can't do it. Many of you must know the answer off the top of your head...
I won't talk about FLTK as I don't know it.
wxWidgets uses the native toolkit of the platform, (GTK on Linux, Win32 GUI API
on Windows, Cocoa on MacOS X).
GTK uses a theming API to fake the look and feel of the platform (custom theming engine on GTK2, CSS-based engine on GTK3).
Qt uses styles to fake the look and feel of the platform.
wxWidgets API is quite ugly from my own experience, because it had too many method just available on one or the other platform making stuff non-portable unless you'd workaround it. Unlike GTK+ and Qt, it also adds its own layer of bugs above the toolkit it uses as a backend. However, it tries hard to have the platform's native look as it uses the native toolkit.
GTK+ 3 still has some rough edges on Windows, which it officially supports since GTK+ 3.6. The GTK+ project delegates to the MSYS2 project the distribution of Windows binaries. As you're already using MinGW, that's pretty much the same kind of environment. They have good C++ bindings with GTKmm. However, you may have some work to get the theming right for your version of Windows.
Qt is a good choice for cross-platform C++ development with the main target being Windows, tries to mimic the native look and feel of the platform but has its own theming limitations too.
To sum up, there are only 2 approches:
toolkits that provide their own widgets and try to look like the native platform by providing theming (GTK+ and Qt)
toolkits that use the native widgets but hide their API behind a layer of abstraction (wxWidgets)
Both have their pros and cons.
Implementation details aside, wxWidgets philosophy is, and has always been, to look as natively as possible. We, wxWidgets developers, don't always achieve the goal of looking indistinguishably from the native applications but we always strive to do it and. AFAIK this is not such an important goal for Qt and definitely not for GTK+, so in my (obviously biased) opinion, wxWidgets is your best choice if you are serious about providing the best experience for your users, especially under OS X.
To answer your question more precisely, everything you list above is implemented using native controls in wxWidgets for Windows (rich text control is not available natively under the other platforms though).
IUP - Portable User Interface library uses native widgets, C API and Lua bindings.
i used java for native cross-platform without changing the code, used c/c++ wxwidgets for exclusively cross-platform if you want go to little up performance and standalone executable, used c/c++ winapi for windows and x11 for gnu linux native platform and terminal console, used python for scripting console and platform if you want your software up to date fast, and used assembly for a little simple purely console. And sometimes i combined them all with shared library .dll on windows and .so on gnu linux. And i liked doing for do comparative performance on programming studies with small hardware requirements.
I am looking to get started with some 3D programming in C or C++. The problem I have is that it seems like the only tutorials I can find for Mac OS use objective C and Cocoa frameworks. I want to obtain the same environment as Windows users, more or less.
If I try to use a text editor and g++ compiler, I am missing headers, but, if I try to use Xcode, I am forced to grapple with Cocoa, which is frustrating to me. I don't really see any reason why the OpenGL/GLUT that comes pre-installed on Mac should force me to use Xcode, but it seems I can't get the header files without it.
How can I get through all of the Apple 'developer friendly' interfaces to write some old-fashioned code with full cross-platform portability?
Some portion of Objective-C is inevitable if you want to use the latest benefits of the OSX/Cocoa. The easiest way to port an existing application to MacOS would be the following:
Write the "bare bones" nibless application in Objective-C. It would only be a single AppDelegate class and a little setup in the main() function
Add the custom NSGLView descendant in your window which you create in the AppDelegate's didFinishLaunching event handler
Setup the CVDisplayLink and rendering callback in the NSGLView initialization
Use your existing OpenGL rendering code in the CVDisplayLink's callback
Now for the interesting part: where to get all of this ?
Surprisingly, a good nibless application sample is the UI for OSX's port of QEMU (yes, the emulator). Also the Apple's official GLEssenstialPractices demo shows all the information you need to set up OpenGL rendering pipeline. All the rest is up to you.
The detailed and modern introduction to system-level OSX programming can be found in the "Advanced Mac OS X Programming" book by Mark Dalrymple. It explains many things and after reading all of this I've understood most of the design decisions in the OS (it really makes you accept all the "non-standard" things if you think from the performance viewpoint).
To get through the "nibless" programming I would recommend you to read the blog posts like this one http://blog.kleymeyer.com/2008/05/creating-cocoa-applications-programatically-ie-nib-less/ The google search helps a lot.
The same tricks apply to the CocoaTouch/iOS and there are a lot of questions answered on SO, like this one Cocoa touch/Xcode - generating NIB-less graphics context
If you want to create cross-platform applications you could create a project with the Command Line Tool template.
Next, import the OpenGL and GLUT framework. This will get you a "blank" C++ project with the required OpenGL and GLUT headers.
Lighthouse 3D gives you some tips about portability and how to initiate your first project.
http://www.lighthouse3d.com/tutorials/glut-tutorial/initialization/
I have created a software layer (named cocoglut) that allows the translatation of basic or essential GLUT calls to COCOA. This library allows creating/destroying windows and register callbacks from a C/C++ application, just by using GLUT calls, without the need for nib files or for XCode project files (and can be compiled from the command line). This option uses full retina display resolution. The source is on GitHub.