OSX

[AIR]

What's the biggest hurdle to having a viable Basic in OSX?

The Gui.  No one seems to want to tackle Cocoa.

Well, I was playing around this evening, and came up with this:

Code: [Select]

#import "aw.h"


dim as id mywin,txtFld,button,combo;

Cocoa_Main
  Start

    Cocoa_Init();

    mywin = newWindow("My Test Window", 600, 400);
    txtFld = TextField(mywin, "Welcome to AIR's Cocoa Demo.", 30, 400 - 42, 410, 22);

    button = Button(mywin,"Load",470, 400 -43, 90,24,@selector(GetFileName:));

    combo = ComboBox(mywin, 30, 400 - 102, 210, 24);
    AddItem(combo,"Apples");
    AddItem(combo,"Oranges");
    AddItem(combo,"Peaches");
    SetText(combo,"Apples");
   
    Cocoa_Run(mywin);

  End
End
So it CAN be done.  Compiled as Objective-C code, it uses a mix of C and ObjC.  All abstracted to allow coding like above.  The actual GUI-producing code lives in a static lib, which is linked at compile time.

See attachment for screenshot.

This is just a proof of concept, I'm not looking to develop this so don't ask! 

BTW this violates pretty much every Cocoa Programming guideline ever published, so no flames!

AIR.

[John]

The Gui.  No one seems to want to tackle Cocoa.

I have been waiting for IUP to do Cocoa but the Important status keeps falling off the list with each release. 

Why Not Mac? The first Mac driver was developed for MacOS 9 and had several memory limitations so it was abandoned. With Mac OS X we have the opportunity to do something better. Today IUP runs on Mac OS X using X11 with Motif or GTK. We plan for the future to build a native driver, but it is not a Tecgraf priority.

Is the above code done with your MBC translator?

[AIR]

Is the above code done with your MBC translator?

Nope, pure C/ObjC, all hand coded.

[John]

Nice!

It's hard to tell it's C/ObjC code.

It's depressing to share good ideas when everyone else seems to have their own. 

[Mike Lobanovsky]

Wow! Cool!!!

Does your static lib support control event handling, AIR?

(P.S. to John: here "Wow" stands for "OMG", not that dreadful MS thing you're so wary about. )

[AIR]

At the moment, there's a callback that I assigned to the button using @selector(..), which pops up an open file dialog.  But that particular callback is hard coded in, because @selector only works with class methods.

There's a way to "inject" an arbitrary function call into the main window (subclass of NSWindow) at _runtime_ so that it becomes accessible as a class method, so @selector() can see it, but I haven't quite gotten there yet.

To be honest, though, I only tried this because a co-worker dared me to.  So lunch was on her today!

Give me a day or so to clean up/add comments, and I'll upload for those interested in taking a look.

[John]

To be honest, though, I only tried this because a co-worker dared me to.  So lunch was on her today!

Who said there is no free lunch? 

[Mike Lobanovsky]

Thanks a lot,

I'll be looking forward to your demo!

And, er, should I also start saving for another free lunch now, Armando?

[AIR]

Attached is the source for the demo.

I ended up not commenting the code; Objective-C is a VERY expressive language and it's fairly obvious what the calls are doing.

For example, placing text into a TextField (Edit Control in Windows) looks like this (nameField is the name of the instantiated TextField):

Code: [Select]

[nameField setStringValue: @"My Name"];
So as a result I didn't bother commenting because it should be fairly easy to figure out what's supposed to happen.

Please check the README for notes etc...

A.

[AIR]

After messing with this a bit more, I decided to forget it and try my hand at getting libclaro fixed instead.  It's an abandoned library, for those who've never heard of it, with no documentation. 

Poring over the source, I figured it out.  I also had to fix a LOT of the code, but I have it working pretty good.

Linking it statically, the binary showcased below comes in at 333KB!.  A FAR CRY from a statically linked WX or QT app.

The best part about this is that it was orginally designed from the ground up to use C, so for all of you bemoaning the lack of a C-centric GUI lib, this might be the one.

It's originally cross-platform (Win, Lin, Osx) but I stripped out all of the Win/Lin code for my port.

Testing it with Bacon on my Mac (I know it works with MBC, but that's CPP-based), here's what I have so far:





I have to create some documentation for this thing, because there really isn't any.  A Doxygen dump doesn't tell you how to USE this lib!   

BTW, this lib supports auto-sizing, so the app above can be run full-screen with all the objects sliding into place nicely.

A.

[John]

Finally a C based GUI toolkit for the Mac.

Looking forward to seeing this unfold!

Perfect world, put an IUP front end on this. All you would need to do is create the libclaro driver.

[Mike Lobanovsky]

My hands are starting to tremble...

[AIR]

Generated some preliminary Api Documentation

[John]

Outstanding job Armando!

Let me know when you're to the point that having Antonio (IUP author) take a look and possibly using this for a driver.

Could you repost your attachment you made on the BaCon forum here as only forum members have access to it there.

[AIR]

As requested, demo attached.