The way I think it's done is: - Write the code that displays the GUI ( Window, Button etc ) and put it in functions. - Give the programmer access to the functions.
So, in essence, if I wanted to write a GUI toolkit for the Windows operating system and the ( for simplicity's sake ) C programming language, I could write the assembly code that displays the ( again, simplicity ) empty window, put it in a function, and ( this part I still need to do some research into ) get it to work with C ( as a header file ). Then I just give the file(s) to another C programmer(s) and they just access the functions in the header file, right?
This sounds to me like the 'G' part of "GUI"--the graphical portion. What I don't see there is the 'UI' part--the user interface. The graphics are a fundamental and necessary part, but IMO, a GUI system also should provide standard functionality to work with input devices as well (mouse and keyboard are traditional :)).
Once you have that, there's a design choice to make: Do you provide a full-blown event-driven window management and messaging system, or do you simply provide the toolkit and leave the main loop up to consumers of your GUI system, or something between the two?Please keep in mind that this is ALL made for simplicity, I actually would like to make it for the LISP language and make it cross-platform. I just want to get the method defined here. Then I can work on details like making it cross-platform and using it in one ( or more ) languages.
Also, so you know, I'm in the designing stage of it right now. I want to get ( at least most of ) it figured out and researched before I start, as I know this will be a major undertaking.
I think you're on the right track here. Design how it should work, then make it happen for one platform--any platform. This will help keep your design issues separate from purely cross-platform concerns.I know some of you will feel obligated to tell me to "just use one of the toolkits already available" or "just join one of the projects already started". While I appreciate your concern for me and my time, I feel that this would be a very good learning experience for me. As well as, since I'm just in the designing phase right now, I'm not completely sure I'm going to do it. There is a lot more research to do before I decide on it. I'm NOT going to run out tomorrow and try to get the whole thing done in a weekend. I'm taking this seriously.
I'm with you on the learning experience thing... When I have the time, I like to roll my own too.
I would recommend, though, that you do examine the existing GUI systems out there to get an idea of what people are already doing, how these systems work, and how nice they are to work with--or not. Studying a GUI system that sucks will teach you just as much as one that works well.
