Google hasn't been very handy, and searching here didn't find anything related to what I was looking for.
I'm looking to find out how GUI's generally work. I don't mean message loops, calls and such. I mean literally, what steps are taken to draw them. It's just something I want to learn about. Just to clarify, I want to know what for example happens when you do CreateWindow, how buttons are drawn. Not the EXACT workings, like how it's done. But more like /what/ is done. Like, once the call is done the X is asked to do X, X then passes this X on. Etc
Anywhere to start would do fine. But surely the way in which a GUI is drawn isn't specific to windows. I mean, engines for example. They follow the same idea. They may use different methods but they all compress and ignite petrol.
Appreciate the reply prime, wxwidgets GTK QT etc, I'm not looking for something to use. I'm looking to learn the idea of how GUI in general works.
Edit: (Sorry) Not loops and such, but I mean. The actual graphical drawing part, what is done to achieve it. Pixel by pixel from what? Etc.
probably that was the idea, to get the source for wxwidgets or else and look inside,
From my point of view the best way is to find a book about xlib, tcl/tk or msn visual studio.
tcl/tk could be strange and probably very hard to understand at first step, so is probably ok to avoid it but in my opinion is the best way to do such things.
Thanks. Xlib is as good an answer as I could ask for. Will get a book on it. Already tried looking in the source of wxwidgets by the way. And I'm sorry but I'm not going through 700 files rofl. I just wanted to know the basic idea of it. Not the exact way.
Thanks. Xlib is as good an answer as I could ask for. Will get a book on it. Already tried looking in the source of wxwidgets by the way. And I'm sorry but I'm not going through 700 files rofl. I just wanted to know the basic idea of it. Not the exact way.
Anywhere to start would do fine. But surely the way in which a GUI is drawn isn't specific to windows. I mean, engines for example. They follow the same idea. They may use different methods but they all compress and ignite petrol.
That analogy isn't really applicable. At a more low level hardware level, yes they all work they same in the sense that they draw pixels to the screen. At a more functional level different platforms handle managing windows differently. Even within Windows now Vista's Aero has changed some of the rules on how GUIs work in the Windows.
Previously in Windows if a window is off the screen or being partially or completely covered by another window, the window area not visible isn't stored in memory. When the area comes back into view the OS sends a WM_PAINT message to the window with the region of the window that needs to be drawn.
However in Vista to implement alt tabbing where you can see what each window looks like or that fancy different windows-tab key combination (I think that's it) where it cycles through all the windows with a bunch of flare; all the windows need to keep the data representing the window in memory. I've actually played around with this. WM_PAINT messages that normally would have been generated aren't because the OS still keeps the entire window in memory even when it can't be seen.
There is a Microsoft utility called Spy++ that lets you watch all the messages being sent to a specific window that is open.
At a more low level hardware level, yes they all work they same in the sense that they draw pixels to the screen.
This is what I wanted to know though. How it decides what pixels to draw to the screen. And how the pixels are 'decided', generated from image files, from maps of pixels, from sprites, how certain sections are decided. Etc etc. But I'm guessing that's exactly what reading about Xlib is going to tell me. I already understand the basic idea of how they work in a higher level. Receiving messages and constantly looping and performing actions based on the messages.
Before you post, read our: 
Graphical User Interfaces
