Developing GUI objects in C - advice needed

I finished my second attempt at a GUI button yesterday (C and openGL). Not great, but it does resize and I can change the label .... AND! the label stays centred throughout the resize. Thanks to the help I got here yesterday, the code is a little more tidy and organised in one place.

However, it still did take a lot of lines of code, started to resemble spaghetti, and started to get pretty complicated. For example it took ages to figure out how the various updating functions affected each other so that I could get resizing to also update the button label so it stayed centred. Then there were loads of little internal functions like shifting between screen and ortho coordinates, which became increasingly hard to keep track of.

It lead me to question a number of things....

1) I have read that OOP is a natural way to program GUIs. People talk a lot about code reuse and inheritance as being some of the reasons for this. Is this true?

a) If so, does this mean it would be better if I started to learn something on C++ or objC (I'm on a mac)

OR

b) Is C a perfectly adequate for the job? ... And if so, are there any top tips for programming GUI objects in C, or is it simply 'code and learn'.

And finally

2) The searches I have made tend to lead me to existing GUI frameworks rather than referring to the process of developing GUI's. Does anyone know of a good basic reference for this which will talk about things like a framework for thinking about GUI code and structure, and concrete stuff such as "Making a button"

Sorry for all the questions and I hope this is not too general a question for the forum.

Personaaly, i think you are wasting your time by re-inventing what is already done for you --- it's called Visual C++. All those GUI items are created for you to use however you wish. You can even create "owner drawn" objects instead of using what is encapsulated in the MFC, e.g., if you want to put some sort of a bitmap over the button, instead of the typical button you see in a standard application. This is my opinion. The thing you need to answer for yourself is this: Can I create a 'better wheel'? Is it worth my time?

Im not sure what you were asking. Do you want to do GUI´s in Mac system. If yes, i would highly suggest you to get familiar with Gtk+.

Good place to start : http://www.gtk.org/documentation.html

And yes you can code with C , C++, Python etc. when using Gtk+.

Quote:

---

Originally Posted by kcpilot

Personaaly, i think you are wasting your time by re-inventing what is already done for you --- it's called Visual C++. All those GUI items are created for you to use however you wish. You can even create "owner drawn" objects instead of using what is encapsulated in the MFC, e.g., if you want to put some sort of a bitmap over the button, instead of the typical button you see in a standard application. This is my opinion. The thing you need to answer for yourself is this: Can I create a 'better wheel'? Is it worth my time?

---

He asked how to do that in Mac. Are there MFC, Visual C++ etc for Mac too?.

Quote:

---

Originally Posted by officedog

1) I have read that OOP is a natural way to program GUIs. People talk a lot about code reuse and inheritance as being some of the reasons for this. Is this true?

---

Yes, OOP lends itself naturally to this kind of tasks, usually.

Quote:

---

a) If so, does this mean it would be better if I started to learn something on C++ or objC (I'm on a mac)

---

If you are going to use OOP, you might as well go all the way C++, since it has many things C does not and simplifies a lot of things, too.

Quote:

---

Originally Posted by Skvr

He asked how to do that in Mac. Are there MFC, Visual C++ etc for Mac too?.

---

MFC is a Framework that is for Windows only.
Visual C++ is a compiler for Windows (comes with the Visual Studio IDE).

Firstly I must say thankyou for the replies. They are very helpful.

Just to answer the MFC / Visual C++ issue, elysia is right as far as I know. However, it's possible to get a free massive zillion megabyte package called XCode. I feel like I'm looking at the controls of an alien spacecraft when I open it. It offers both an IDE and something called "interface builder" which lets you drag and drop buttons, Opengl contexts, textfields, speadsheets, set IBOulets and boatloads of shiny widgets from the Appkit framework.

Problem is, with my stage of understanding (I am self taught) I've followed tutorials successfully but never really felt like I understood it, so could not easily do anything other than the tutorials. Also, the native language is objective C which adds further to the learning curve. In contrast, I feel like I'm making good progress with understanding C and opengl.

kcpilot - You ask a good question and I had the same question also yesterday. My bicycle definitely has square wheels. But my instinct is to continue on with this track for now, and hopefully start using other people's wheels soon once I have a better understanding.

skvr - thanks for this link, I just had a look. It looks very interesting package which might be the wheel kcpilot was talking about. I'm wondering if I can get an opengl window embedded in it.... I'll have a search on this.

elysia - this is a very useful prompt to get started on C++ (and perhaps not feel too guilty when I accidentally use the odd C++ string now and then). I will brush the dust off my C++ book right away and see where this leads.

Thank you again, I really appreciate the comments.

Quote:

---

Originally Posted by officedog

elysia - this is a very useful prompt to get started on C++ (and perhaps not feel too guilty when I accidentally use the odd C++ string now and then). I will brush the dust off my C++ book right away and see where this leads.

---

Well, everyone must start off somewhere, right? So do not feel ashamed of sticking to "C+" as we call it, in the beginning. If you continue to study C++ after that, you might just become a true C++ programmer one day.
And perhaps, if you wish it, even be able to do both.

For Mac, the preferred API is typically Cocoa. That is in Objective-C. There is also Carbon and Core Foundation. Carbon is in C, and I think Core Foundation is too.

http://developer.apple.com/mac/
http://developer.apple.com/referencelibrary/Cocoa/
http://developer.apple.com/referencelibrary/Carbon/
http://developer.apple.com/reference...oreFoundation/

Or you could develop for X11.

http://developer.apple.com/opensource/tools/X11.html

It might also be noted that many graphic APIs are C, but that does not stop programmers from typically using C++ when writing a game (most games, if I am not mistaken, is written in C++).
Since C++ is backwards compatible with C, using a C(objective) API is of no problem.

Well, using the C++ backwards compatibility to use C and C++ in the same project is kind of a halfway solution. A better option would be to use extern "C" to get C linkage for your C code to use real C and real C++ in the same project.

Yes, you could use C and Objective-C in the same file. If you wanted to use Objective-C and C++ in the same file, I think Apple provides an Objective-C++ compiler.

God bless you for throwing Objective-C into the project. People just don't use it as much these days.

http://developer.apple.com/unix/toolkits.html

Thankyou for these helpful links and thoughts robwhit. I currently use GLUT (I see it mentioned in that last link) as the very basic windowing system although I hadn't really thought of it as a GUI before. I don't think it does buttons and text boxes, but I have seen someone use a drop down menu. However, it does have lots of callback functions (e.g. passive mouse movement, mouse click and drag, keyboard input, reshape) which I can now understand enough to 'wire up' some parts of the interface. I'm going to stick with this for just now, have a go at creating a 'reuseable' button and text box. About your 'extern C' comment - I am taking from this that if I open a .cpp file and write C code, the extern C is needed if I want the pure C code to be run through the pure C library rather than the C++ library. This might not be an issue right now, but I will keep it in mind.

On the OOP issue, I did open my C++ book, and then suddenly stopped and returned to something I remembered seeing before - there is a lecture series available on the internet from stanford university, and one of the lecturers there Jerry Cain talks about how one could best replicate an OOP style in pure C. I thought this might be a useful path to follow.

If anyone is interested, here is the link (he likes talking about void* a lot)

Stanford lectures: Jerry Cain

The lecture I am referring to starts towards the end of lecture 5 (I just checked - it's about 37 minutes into the lecture) and into the beginning of lecture 6. I found it very interesting. I'm going to experiment with this today.

All extern "C" does is tell the compiler "this function should be called as if it were a C function." It doesn't mean the code inside the function is C, it just mean that code should assume that the function is written in the binary so that you can call it like a C function, not a C++ function. C++ sometimes names the function in the binary file as something different than what C usually would do (it's called name mangling). So int func(void) in C++ and int func(void); in C might not mean the same thing. Use extern "C" int func(void); in C++, and int func(void); in C to get around that.

YES I would really suggest you to start using C++ and try pulling all your C code into the C++ classes. This allows you declare object of kind and try use then. If else, it would be paining in the ass to try integrating all small parts of the graphics to one single bundle and try operating all those object simultaneously. Even through the GLUT library seems to provide you some routines to do that!

ssharish