Okay,
I have been thinking about writing a GUI toolkit recently, and after doing some searching on the web, I haven't found much on it it's self. But I believe I have the basic idea down, and I was wondering if you guys who maybe know about this could let me know if I am doing this right before I start with loads of work.

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.

Sounds very simple to me. Having said that, I would like to point out that by "simple" I do NOT mean "not a lot of work". I just mean that the process is not incredibly complicated.

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?

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.

And thirdly, 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.

Having said that, I would appreciated any advice and/or CONSTRUCTIVE criticism on this idea/project.

Whew! That was a lot to get off my chest. Now, it is up to you guys who are willing to help me out with this by sharing your knowledge and/or experience in this area. So please, share with me what you can. I'm ready to know, and thirsty for knowledge.

Sincerely,

- WolfShield ( James )

*Bump*

Any advice on this would be great.

- WolfShield

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.

gusano79,
Thank you very much for you reply and understanding. I have already used a few different GUI toolkits, but your suggestion is a great one! I'll be doing some more coding in the other ones I can find.

As far as what kind of GUI library to make, that is a great place for me to start in design! Thank you very much for this incite, it will be a great push in the right direction.

And for my initial method ( one OS first ), glad to hear that I'm at least starting it the right way. :)

Once again, thanks a lot gusano79.

Sincerly,

- WolfShield

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.