macOS Simple custom windows using CARBON?

[jungledmnc]

Hey folks,
I have probably a very simple problem, but since I'm a more like Win32/Linux programmer, I found Mac OS X API so so so complicated and I even couldn't find any useful docs or samples.

So I need to create a simple window without title (since I have my own) and be able to paint in it (only bitmaps, since all rendering is customized), handle all necessary events, such as mouse/keyboard... custom GUI.

I was able to create a window, handle mouse events. But I'm still unable to paint into the window!!! What a basic task?? There are many events such kWindowDrawFrame, kControlDraw etc. I don't know what is the difference, but what I want is the most simple approach:

1) OS needs to redraw part of the window -> sends an event or something -> I'll paint it

2) When I need to redraw part of the window (e.g. user clicks on a widget), I need to tell the OS to "invalidate" it and let me redraw.

Can you please point me somewhere?
Thanks in advance!

 

[Eraserhead]

Carbon has basically been depreciated as it doesn't (and will never) have a 64 bit version. You should be using Cocoa going forward.

The documentation does include Cocoa sample code, though to start off you're probably better off with a book like Aaron Hillegass's one.

 

[jungledmnc]

But Cocoa is for Objective-C only, right? I need "C++".
Really, if Apple is going to stop releasing development applications in "C++" for 64-bit, they will have a really big trouble, since one of the final applications for Macs are audio and graphics. And these apps are rarely single-platform, since not many people are going to forget about the most widespread platform, Window. Can you imagine Photoshop or Cubase for Mac only? I don't...

 

[kainjow]

Your application doesn't sound that complicated. If you're not using built-in user interface controls, then there isn't much setup, and it's just a matter of figuring out how to use your drawing routines with Quartz and handling NSEvents. The reason you're probably not finding many examples is because like Eraserhead said Carbon is practically deprecated for new development.

Using C++ with Cocoa has been discussed many times before. This thread may be of some interest:
https://forums.macrumors.com/threads/246143/

 

[iJed]

But Cocoa is for Objective-C only, right? I need "C++".
Really, if Apple is going to stop releasing development applications in "C++" for 64-bit, they will have a really big trouble, since one of the final applications for Macs are audio and graphics. And these apps are rarely single-platform, since not many people are going to forget about the most widespread platform, Window. Can you imagine Photoshop or Cubase for Mac only? I don't...

There is nothing to stop you calling C (or C++) code from Objective-C(++) and building the UI with Cocoa. Of course you'll have to learn Obj-C, but even with that overhead Cocoa is a drastically more productive environment than Carbon ever was.

There is little point bothering with Carbon nowadays as its days are likely numbered for inclusion in OS X. After all it was created for the purpose of making the porting of classic Mac OS applications to Mac OS X easier.

You do have other choices like wxWidgets and Qt but if you actually want any Mac users to use your app its not really worth bothering with.

 

[jungledmnc]

The thing is, I'm implementing port for something like Qt (oriented for little different applications). So I want it to be completely C++ and I truly don't see a reason to use complicated interlanguage solutions, when I want something so simple. The source code must be the same for all platforms.

I think it should be really simple. Most of the library is already ported, but the GUI. And now I was kind of experimenting, and so far I was just unable to "draw" anything into the window.

Please please, really there is nobody knowing how to do such a thing? Or at least navigate me somewhere like "you simply have to use this even for the window, get this from it, and to invaluidate part of the window call this". I found a different library doing almost the same thing (I guess), but they are creating subcontrols for unknown reasons etc.

 

[Thomas Harte]

The thing is, I'm implementing port for something like Qt (oriented for little different applications). So I want it to be completely C++ and I truly don't see a reason to use complicated interlanguage solutions, when I want something so simple. The source code must be the same for all platforms.

There's noting whatsoever complicated about it. Here's a method for some arbitrary C++ object that creates a new instance of a C++ class and issues a call to it:

void ArbitraryClass::AddNewObject()
{
   OtherObject *object = new OtherObject;
   object->DoSomething();
}

Here's a method for some arbitrary Objective-C object that creates a new instance of a C++ class and issues a call to it:

- (void)addNewObject
{
   OtherObject *object = new OtherObject;
   object->DoSomething();
}

I don't see how you could characterise that as a "complicated interlanguage solutions". By the same token, you'll probably be aware that Apple provide a whole bunch of industry standard APIs like OpenGL, OpenAL, etc, as part of the OS. Those are accessed directly through their C APIs, so you might see the following:

- (void)drawQuad
{
   glBegin(GL_QUADS);
      glVertex2f(-1, -1);
      glVertex2f(1, -1);
      glVertex2f(1, 1);
      glVertex2f(-1, 1);
   glEnd();
}

Which by your measure would mean that every 3d OS X application is somehow more complicated than it would be if written in C++?

I think it should be really simple. Most of the library is already ported, but the GUI. And now I was kind of experimenting, and so far I was just unable to "draw" anything into the window.

It'd actually be more simple with Cocoa than with Carbon. Carbon is designed to work on either OS 9 or OS X. That means it is written to deal with two possible compositing models, either the decrepit drawing of regions directly to the framebuffer every time something is raised or moved, or the fully buffered window contents of OS X. Cocoa deals exclusively with fully buffered window contents and as a result doesn't have a multitude of messages that you need to pick your way through to figure out exactly what sort of redrawing it is asking for.

Please please, really there is nobody knowing how to do such a thing?

It's actually possible that nobody here does know how to do such a thing, Carbon now being an ancient figment from a time of much lesser Apple market share.

Or at least navigate me somewhere like "you simply have to use this even for the window, get this from it, and to invaluidate part of the window call this". I found a different library doing almost the same thing (I guess), but they are creating subcontrols for unknown reasons etc.

My tip is that you'd probably be best off checking out something like the Mac-specific code from the SDL or Allegro game libraries. They explicitly try to do exactly what you want to do — i.e. just push out some pixels, damn the look and feel — and I know for sure that SDL in 1.2 and Allegro in 4.2 and earlier use Carbon to achieve it. If you can stand the "complicated interlanguage solution" then check out files such as https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/4.2/src/macosx/qzwindow.m.