- Forum
- General C++ Programming
- The promise of GUI on all platforms
The promise of GUI on all platforms
In the early days of my programming hobby, I wrote for DOS and if I wanted a button, I had to draw it, watch it, react to it, etc. Fast forward to the coming of the GUI. The way I heard it, this revolution in computer interface would make it so the OS would handle all the real low-level hardware and event related things. They would all (supposedly) offer an easy to use API that would handle many things like graphics, printing, sound, etc. so the programmer wouldn't have to be burdened with that stuff.
Here we are in 2021 and the 3 major GUIs (A,U,W) all have established pretty well and are being used everywhere. However, I'm still waiting for this magical API that I was promised. Let me explain what I mean by that.
When I was writing assembly code for DOS, I had a huge book published by Microsoft that had a list of all the API functions available in DOS. There was also a 2nd section with a complete list of API functions of BIOS. Each page would list a function, how to place the parameters to call the function and what to expect as a result. It would also give a short example of use. Where is the equivalent for the GUIs? I would expect the basic functions of a program that they all have should be outlined just like that. For example, windows, menus, events such as opening and closing, resizing, moving of windows, etc. were supposed to be available to the programmer and easy to use without a lot of re-inventing the wheel.
Is there a point to this? Yes. I'm making a small program in C++ using SFML for the window and the graphics and I want a fully functional menu. I know about QT and I've tried it more than once with less success than I'd hoped for. I've tried other things, too and I'm still pretty much at the beginning.
I have done some research and so far have only found menus made using std::cout or defining a menu class using a new window for the menu. Needless to say, these are nowhere near what I want.
Is there a current documentation that allows low-life programmers such as myself to use the GUI's API? Obviously it must exist somewhere because people are writing programs.
Here we are in 2021 and the 3 major GUIs (A,U,W) all have established pretty well and are being used everywhere. However, I'm still waiting for this magical API that I was promised. Let me explain what I mean by that.
When I was writing assembly code for DOS, I had a huge book published by Microsoft that had a list of all the API functions available in DOS. There was also a 2nd section with a complete list of API functions of BIOS. Each page would list a function, how to place the parameters to call the function and what to expect as a result. It would also give a short example of use. Where is the equivalent for the GUIs? I would expect the basic functions of a program that they all have should be outlined just like that. For example, windows, menus, events such as opening and closing, resizing, moving of windows, etc. were supposed to be available to the programmer and easy to use without a lot of re-inventing the wheel.
Is there a point to this? Yes. I'm making a small program in C++ using SFML for the window and the graphics and I want a fully functional menu. I know about QT and I've tried it more than once with less success than I'd hoped for. I've tried other things, too and I'm still pretty much at the beginning.
I have done some research and so far have only found menus made using std::cout or defining a menu class using a new window for the menu. Needless to say, these are nowhere near what I want.
Is there a current documentation that allows low-life programmers such as myself to use the GUI's API? Obviously it must exist somewhere because people are writing programs.
| the 3 major GUIs (A,U,W) |
| I'm making a small program in C++ using SFML for the window and the graphics and I want a fully functional menu. |
If you want something more like a standard Windows application that follows the system's look and feel, that's entirely different.
| Is there a current documentation that allows low-life programmers such as myself to use the GUI's API? |
I think it's pretty pointless to go with the raw system functions nowadays, unless you're going for an executable with minimal dependencies. It's much more practical to go with a widgets toolkit like Qt or wxWidgets, or even a language with built-in GUI support. Personally, these days I write all my GUIs in C# and just write a backend library in C++ if I need one.
Last edited on
apple unix windows?
which is flawed in and of itself...
apple I do not know anymore, but unix has 3, maybe 4 major gui you can pick from, and windows are built from at least 3 major libraries, if not 4-5. Hard to draw the lines on major/ minor there.
I am with Helios... do the gui in whatever is easy and invoke the c++ behind it, esp for windows.
QT's claim to fame is portable.
So, to the OP.. back off, and research the options (people here can help you with it), then pick one that suits, then learn that API and use it.
the good news is they do still work like your hands-on dos experience. There is a graphics component, often little more (for say a button) than a relative offset into the window and a size, text label.... and there is a listener and handler invoked when it is heard (mashed). Nothing new there, though some(most?) of it is hidden / done for you of course.
which is flawed in and of itself...
apple I do not know anymore, but unix has 3, maybe 4 major gui you can pick from, and windows are built from at least 3 major libraries, if not 4-5. Hard to draw the lines on major/ minor there.
I am with Helios... do the gui in whatever is easy and invoke the c++ behind it, esp for windows.
QT's claim to fame is portable.
So, to the OP.. back off, and research the options (people here can help you with it), then pick one that suits, then learn that API and use it.
the good news is they do still work like your hands-on dos experience. There is a graphics component, often little more (for say a button) than a relative offset into the window and a size, text label.... and there is a listener and handler invoked when it is heard (mashed). Nothing new there, though some(most?) of it is hidden / done for you of course.
Last edited on
| I had a huge book published by Microsoft that had a list of all the API functions available in DOS. There was also a 2nd section with a complete list of API functions of BIOS. Each page would list a function, how to place the parameters to call the function and what to expect as a result. It would also give a short example of use. Where is the equivalent for the GUIs? |
I've got the same book 'The MS-DOS Encyclopedia' Excellent in it's day!
Well for the WIN32 API there is the 'Windows 2000 API Super Bible'
https://www.amazon.co.uk/Windows-SuperBible-Simon-Richard-Paperback/dp/B011YTSWWI/ref=sr_1_3?dchild=1&keywords=windows+2000+api&qid=1624184428&s=books&sr=1-3
This is the update for the author's book 'Windows 95 WIN32 programming API Bible'. And for Windows common controls. there is 'Windows95 Common Controls & Messages Bible'
https://www.amazon.co.uk/Controls-Messages-programmers-reference-1996-04-02/dp/B01K17NWUG/ref=sr_1_1?dchild=1&keywords=windows+95+common+controls&qid=1624265753&sr=8-1
Microsoft also produced reference books for C++ MFC library. I think this was last updated for VC++ 6 (1998) !
That Windows API book hasn't been updated since as really in these days of the internet books like these just aren't needed/produced any more. There's more up-to-date info on-line with just a few moue clicks!
But no-one starts new gui projects using WIN32 API (or unlikely MFC) these day!
You mention SFML. There are books available (I counted at least 6 on Amazon). The SFML website has it's own forum, documentation and tutorial etc...
Last edited on
But no-one starts new gui projects using WIN32 API (or unlikely MFC) these day!
mfc works fine in 64 bit compiles and is still fine if you don't want to deal with the !c++ language.
They can't quite kill it off... some places do still use it. Whether they should or not.
I certainly would not recommend it as your starting point, but, it is simple, in a "we renamed everything in the language for fun" sort of way.
mfc works fine in 64 bit compiles and is still fine if you don't want to deal with the !c++ language.
They can't quite kill it off... some places do still use it. Whether they should or not.
I certainly would not recommend it as your starting point, but, it is simple, in a "we renamed everything in the language for fun" sort of way.
Topic archived. No new replies allowed.