AllBASIC Forum
BASIC Developer & Support Resources => Open Forum => Topic started by: AIR on March 17, 2014, 07:50:31 PM
-
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:
#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.
-
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?
-
Is the above code done with your MBC translator?
Nope, pure C/ObjC, all hand coded.
-
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. ???
-
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. :D)
-
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.
-
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? :)
-
Thanks a lot,
I'll be looking forward to your demo!
And, er, should I also start saving for another free lunch now, Armando? :)
-
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):
[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.
-
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:
(http://recursivemedia.net/screenshots/libclaro/shot1.png)
(http://recursivemedia.net/screenshots/libclaro/shot2.png)
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! ;D
BTW, this lib supports auto-sizing, so the app above can be run full-screen with all the objects sliding into place nicely.
A.
-
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.
-
My hands are starting to tremble... :D
-
Generated some preliminary Api Documentation (http://recursivemedia.net/claromac)
-
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.
-
As requested, demo attached.
-
Thanks!
Any good / free OSX emulation options that would run under Linux so I can try/test this?
-
If you mean something like Wine, then no.
VMWare is your only option.
-
I would be happy to boot off an OSX partition on my 4 TB USB drive if it's possible.
-
Google "Hackintosh" if you want to try to do it as a native boot.
Otherwise, VMWare is your only option for FULL virtualization. Virtualbox doesn't even come close.
-
Hello AIR,
Worked quite well for me, thanks! And the API reference is quite comprehensive even at this preliminary stage. :)
Can you also point me to where the library may actually be downloaded from and also what license it is covered with?
[EDIT] Oh, I've found the both git repos myself via Google and the Mozilla license too. In your earlier Claro-AIR thread (which I can't find on the forum any more for some unknown reason BTW) you said you hadn't uploaded your mods to your repo at that time yet. Are the sources fully updated now, six months later? I'm not so much interested in Nimrod as such but I'd love to try the library out with bare-bone ANSI C.
Regards,
-
Hello John,
I'd also say that your only feasible option is raw VMware Workstation 10.0.0. Apart from this SW being not free, you'll need to go through a lot of hacking to make it work for Mac guests on anything other than Mac hosts which is also contrary to the Apple license. But even then, you'll be also limited to a rather narrow range of supported CPU's, mobos, video and sound cards.
Are you ready for that? ;)
-
I'm counting on you and AIR for MAC support. I have Windows and Linux covered. I was hoping for something I could just test code on and that is about it. I have never owned any Apple products.
-
Hello John,
I'd also say that your only feasible option is raw VMware Workstation 10.0.0. Apart from this SW being not free, you'll need to go through a lot of hacking to make it work for Mac guests on anything other than Mac hosts which is also contrary to the Apple license. But even then, you'll be also limited to a rather narrow range of supported CPU's, mobos, video and sound cards.
Are you ready for that? ;)
Actually, VMWare Player is all you need, with just a patch applied. ;D
-
The correct version of VMware Player, I'd say, as well as the correct version of CPU that's capable of hardware virtualization and has a decent frequency of at least 3GHz, and also a mobo that has the correct version of AC'97 or HD Audio chip that a particular OS X's kexts are capable of detecting and handling. Modern VMware mostly channels the guest operating system through to the host's hardware and the guest is supposed to be equipped with the appropriate drivers itself.
You've just been very lucky with your hardware, AIR, to have your Mac guests running under alien hosts out of the box, patch or no patch. :)
-
I'm using Player version 6.0.1 build-1379776 under Windows 7, on a run of the mill Dell Optiplex 7010.
The thing is, VMWare already supports running OSX SERVER out of the box, so support for the OS is already provided. It just needs a little "coercion" so it will run Desktop versions. Not OSX, but VMWare.
The main advantage of doing it this way is that for all intent and purposes you are running stock OSX. No kext injections, no cobbled together drivers, your running what Apple provides, with VMWare's emulation layer handling all of the things that will drive a person running a Hackintosh nuts (My first "Mac" was a Hackintosh on a Thinkpad T40 laptop. Really enjoyed the OS, and took the plunge for real soon after). So unlike when running on a "Hack", software updates don't break anything.
Mini Rant:
People can say what they want about Apple hardware being pricey, but I don't know too many people on other platforms running on hardware built in 2008 that can still keep up with today's computing demands like my Mac Pro. And in 64bit at that. So for me, the money was well spent because that machine is STILL my primary workhorse.
-
My current desktop config is roughly equivalent to an OptiPlex 7010 with genuine Intel® Core™ i5-3470 Processor (Quad Core, 6MB Cache, 3.20GHz w/ integrated HD2500 Graphics and HD Audio) except for the 8GB of DDR3 RAM and a triplet of monitors (1 on-board Intel + 2 SLI-ed nVidia geForces). So all OS X's from Lion to Mavericks are able to natively detect and support this configuration in both VMware and the raw "Hack" way. Lion's sound is however very poor (presumably due to poorer implementation of its native audio kext) compared to Maverick where I'm getting perfect music-quality stereo sound the both ways. No extra kext injections are required and I'm pretty happy with that.
My former Core2 Duo config did not allow me to go higher than Mac OS X Tiger which didn't have native kexts to support any HD Audio at all or the AC'97 chip version that my former motherboard was equipped with.
I can't afford buying a genuine Mac myself but my elder son promised to present me the 2 year old MacMini that they are going to replace with some new Mac HW at their office in the near future. :)
-
Hey, can you guys take a look at the attachment and tell me if it makes sense?
Thanks,
A.
-
Is there a VBox like control? It would be very difficult to layout that Customer Maintenance screen I did in IUP without it.
-
It would require a rethinking of your approach.
But it is do-able. No Vboxes.
Now answer my question. ;)
-
Now answer my question.
I did. No VBox. :-\ I was hoping this could be used for a OSX driver for IUP.
How would I control container resizing, frames, ...
I think you need to rethink this. ;)
-
Hello Armando,
Thanks for the invitation and the effort you've put into your tutorial.
My case won't be clean as I have already read the principles of Claro layout scripting before from the developer's repo. Yet here's my vision of the subject.
1. You do need the coordinate system idea at least to notify the end user that its origin lies in the top left corner of the main window. Then you can safely switch over to the top-down line-by-line concept.
2. The [ {} | () ] notation does seem intuitive enough to describe control positioning in terms of top-down gaps between the lines (from the lowest Y of preceding line to the highest Y of the line that follows) and left-to-right spaces between the controls within the lines (or "blocks" as you're calling them).
3. The angle bracket notation would be much, much more intuitive if the brackets pointing to their respective anchors were also placed on the respective sides of the labels they belong to: < label >. This may however imply revisioning (extending) Claro's layout script parser but it's unlikely to break its compatibility with the layouts existing in the language(s) where Claro is or may be used.
As for your tutorial:
1. IMHO it needs a little restructuring so that the description of each successive line ("block") is grouped in a clearly identifiable and complete text section. Once described, the preceding line ("block") should ultimately be never referred to again in the sections that follow.
2. The tutorial describes how the controls are positioned and anchored within the limits of their respective lines ("blocks"). But where is the description of how the controls' heights are to be fine tuned with respect to each other within the same line ("block")? And also, what parameters would control the overall height of a line ("block") resizing its controls proportionately to their fine-tuned sizes?
Regards,
-
Why create yet another GUI direction when you could fill a huge hole in the IUP offering on OSX and be a star for doing it. I thought you were a open source / cross platform kind of guy and your current direction doesn't seem to make best use of your talents. IMHO
I'm holding out for Antonio finding time to do it right on OSX.
-
Hello John,
(Who's the mysterious Antonio you're talking about here? :) )
Your attitude is totally Linux-centric. Such frameworks as IUP, SDL, Gtk+, wxWidgets, Qt etc. etc. etc. are sort of systemic and native only to *nixes. They are alien and under-developed under Windows and even more so, under Mac. They are ridiculously huge and their look and feel is hopelessly amateurish by the standards of leading non-Linux OS GUI's.
For me, using a non-system GUI library or framework of a few dozens megabytes to serve my 600 kilobytes-only worth of Windows FBSL is totally out of the question. The situation gets much worse under OS X where an application is actually a separate package, a disguised subfolder tree of everything that's needed for proper functioning of the core binary. The application is not supposed to install anything at the system level for the sake of keeping the Mac system's integrity and the supplier's liability intact. Now imagine me shipping my multi-platform FBSL apps to the Mac users re-installing a set of Qt 5 redistributables in each and every application subfolder tree I create on their computers!
OTOH ClaroMac (and ultimately a multi-platform reincarnation of the entire Claro) may be adding only a few hundred kilobytes of statically precompiled or dynamically loadable code (dll/so/dylib) to such FBSL binaries, and the resultant look of their GUI's will be absolutely natural to the respective platform. Simply because Claro will only be a very thin abstraction layer between FBSL and the platform's native GUI subsystem.
Of course it will carry only a basic set of most common controls. But look at VB6 - it's been using about a couple dozens such controls for decades and it is still around and used by millions of people for both business and fun.
I see great potential in Claro(Mac) and I'll try to do my best backporting Armando's efforts to Windows and Linux' Gtk3 because I have personal interest in using it for the upcoming versions of FBSL or whatever it's going to be called in the future.
-
Antonio is the primary author of IUP. IUP is not Linux centric and uses the native GUI of the platform it's running on. (winapi on Windows, Gtk3 / Motif on Linux., Gtk3 / Motif on OSX - using a common driver API)
The above is why I'm pestering AIR to consider doing the IUP driver for OSX with Claro. He wouldn't have to worry about docs, design and walks away a hero.
-
Antonio is the primary author of IUP.
Nice to see you on close terms with major project leads. :)
... Gtk3 / Motif on OSX ...
I can't see how IUP can be currently related to OS X at all. AFAIK it's been officially supporting Windows natively and Linux via Motif. Its support of Gtk+ started with Gtk3 only. Nothing is being said openly about any form of official support on OS X platforms at all.
The above is why I'm pestering AIR to consider doing the IUP driver for OSX with Claro.
Or he can make his own proprietary driver and use it exclusively in his own projects. IUP goes under MIT. ;)
And it won't actually be "with Claro" but rather "instead of Claro". But the tasks are incongruous, manpower-wise.
Yet as I said, I still can't imagine FBSL being distributed with nearly 40 DLL's under Windows, or nearly 40 DYLIB's in each app package, on a Mac. ;)
-
Important: IupGLCanvas in MACOS X using native OpenGL support.
Important: A MacOS X native driver using Carbon or Cocoa.
As long as OSX stays on the the list and seems important to them, I would assume it will happen some day. I don't do OSX so it's not keeping me up at night.
If Apple would get serious about the business customer, maybe more library projects would be motivated to port their efforts. Consumers don't need IUP or GUI toolkits in general. I don't know how active/large the Apple developer network is.
Yet as I said, I still can't imagine FBSL being distributed with nearly 40 DLL's under Windows,
You must be counting all the Lua DLLs. I can create most standard GUI form work with just the iup.dll. I think the Script BASIC IUP extension module that covers most of the IUP API (Canvas Draw, Extended Controls, ...) is only using 3 IUP DLLs.
Nice to see you on close terms with major project leads.
Antonio is like Charles of the GUI toolkit world. Our correspondence is mostly me bitching or wishing about something. :)
-
Why create yet another GUI direction when you could fill a huge hole in the IUP offering on OSX and be a star for doing it. I thought you were a open source / cross platform kind of guy and your current direction doesn't seem to make best use of your talents. IMHO
I'm holding out for Antonio finding time to do it right on OSX.
I get the feeling that Iup will never be native on the Mac at this rate. If you had any understanding of the challenges involved, you wouldn't be so quick to judge. There is almost NO info in the wild for doing a full fledged Mac COCOA app in code.
I look at how long it took the Purebasic guys to get to Cocoa and I fully understand why it took so long.
The other thing is that after working with Iup ( you DO remember that I did the first Scriptbasic extension for it, right?) that I just flat out don't care for it. So there is no incentive for me to deliver on THEIR promises.
-
Important: IupGLCanvas in MACOS X using native OpenGL support.
Important: A MacOS X native driver using Carbon or Cocoa.
As long as OSX stays on the the list and seems important to them, I would assume it will happen some day. I don't do OSX so it's not keeping me up at night.
CARBON? That's been in the process of being phased out for years. Plus you're limited to 32bit apps.
If Apple would get serious about the business customer, maybe more library projects would be motivated to port their efforts. Consumers don't need IUP or GUI toolkits in general. I don't know how active/large the Apple developer network is.
,
Since you don't own or use a Mac, you don't know what you're talking about. I work for a multi national corporation, and we use Macs for business everyday. So do our competitors.
-
There is almost NO info in the wild for doing a full fledged Mac COCOA app in code.
That sounds pretty scary. How many developers does Apple have that would be skilled enough and have inside knowledge to create real OSX apps? I can understand why no one cares about developing for Apple. Does you company only run shrinkwrap Apple apps?
The other thing is that after working with Iup ( you DO remember that I did the first Scriptbasic extension for it, right?) that I just flat out don't care for it. So there is no incentive for me to deliver on THEIR promises.
Don't forget about 64 bit, Mini XML, SQLite3, help getting Android going, ... Yes, you are deeply missed at the Script BASIC project. Thank you for everything thing you have done. The project never would be where it is today without you.
-
http://www.apple.com/osx/apps/app-store.html
And thousands more on the web
http://www.raywenderlich.com/17811/how-to-make-a-simple-mac-app-on-os-x-10-7-tutorial-part-13
After reading that, you'll understand WHY you don't normally do the GUI in code.
-
After reading that, you'll understand WHY you don't normally do the GUI in code.
(http://cdn3.raywenderlich.com/downloads/ErnestoGarcia.png)
Would you argue with anything this guy says? I wouldn't even want to sit across the table from him. I bet he could burn a hole through your chest by just staring at you. :o
-
On skimming through the tutorial, I'm inclined to think there's a masonic conspiracy impregnating the entire Mac dev community. Seems they are unaware of competitor operating systems' RAD's and their contemporary level of code generation automation. Their Xcode environment looks like a refined sado/maso torture chamber to me. I'm leaving the "beauty" of Objective-C language proper outside the scope of this discussion. :D
-
Resurrecting this thread from the dust-bin.
Since my last post, I've made a ridiculous amount of changes to Claro (now ClaroMac).
I've implemented a NATIVE MacOS layout system, instead of the odd layout in the original. This came about because the previous layout system would consistently crash under Nim, so I decided to "go native".
I haven't generated updated API documentation yet, but you could have a look on my bitbucket repository, which is now public.
https://bitbucket.org/Airr/claromac
Take a look in the "examples" folder to see how it's used. The Bacon Thesaurus example is the only fully functional example (Nim to be completed soon).
Note that I've made this Mac-only, no Win or Linux GUI support (they already have various frameworks).
AIR.
AIR.
-
Damn it's good to see you posting again. I thought you were dead. :'(
-
Hi Armando,
Long time no see indeed. :)
1. Why does the dialog widget remain unimplemented?
2. Do you plan to extend the library's common dialog palette any further?
-
Hi Armando,
Long time no see indeed. :)
1. Why does the dialog widget remain unimplemented?
2. Do you plan to extend the library's common dialog palette any further?
1. On the ToDo list
2. What did you have in mind?
-
Thanks for the feedback, AIR.
I meant more common dialogs like Color Dialog, Find Dialog, Replace Dialog etc. if available under Mac OSX. Also, I saw a couple of functions related to File Open/Save As functionality in the /Platform subfolder IIRC but I don't see the corresponding widgets on the list.
-
Thanks for the feedback, AIR.
I meant more common dialogs like Color Dialog, Find Dialog, Replace Dialog etc. if available under Mac OSX. Also, I saw a couple of functions related to File Open/Save As functionality in the /Platform subfolder IIRC but I don't see the corresponding widgets on the list.
Color Dialog is something I could do, since the Cocoa Framework has that. Find/Replace dialogs are custom windows displayed modally or in a sheet.
Open/Save is something I did a while ago, guess I forgot to update the widget list.
I've implemented Alert dialogs, see the test2.bas in the mbc folder to see how it's called/used (that example uses the old layout system, too lazy to redo it!). Right now dialogs have hard-coded "Ok" and "Cancel" buttons, will add support for customized labels and more buttons on dialogs in a day or so.
AIR.
-
Great stuff!
Curious. Would SB be able to use your library on OSX?
Secondly, have you looked at Swift?
-
Cool!
In fact, I'm feeling rather excited about ClaroMac as #1 GUI candidate for my future work on a multi-platform BASIC/C/Asm jitter. The native OSX GUI seems to be the most mysterious part of the project, and once ClaroMac is more or less functional, it can be backported to Linux/Windows to ensure functional consistency throughout the three platforms. Granted its versatility is rather limited yet but it being written in a straight-forward procedural C as well as its small size are a definitive plus to start building my new jitter project off of.
Thanks for sharing you work, Armando!
-
Great stuff!
Curious. Would SB be able to use your library on OSX?
It should be able to, but you'll need callback support like with just about every other GUI toolkit.
Secondly, have you looked at Swift?
Yes I have, but I don't particularly care for it. I'm used to the square-bracket syntax of ObjectiveC.
AIR.
-
Granted its versatility is rather limited yet but it being written in a straight-forward procedural C as well as its small size are a definitive plus to start building my new jitter project off of.
That's encouraging news. (C)
-
Hi Armando,
I've implemented a NATIVE MacOS layout system, instead of the odd layout in the original.
Does that effectively mean that the original Win/Lin Claro's entire control layout scripting engine is disabled, null and void in ClaroMac? (its source files still seem to be present in ClaroMac/src/ tho... ::) )
Can you give me any clues as to where I can read up on common/recommended practices to implement ClaroMac-compatible user drawing? Currently, its Canvas widget seems to be nothing more than an empty stub.
TIA
-
Hi, Mike.
The original layout engine is still in place so it can still be used.
For custom controls/drawing, take a look at: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CocoaDrawingGuide/DrawingEnviron/DrawingEnviron.html
-
Observation:
It is interesting how OSX has become a common ground for Windows and Linux developers. A dash of commercial with a pitch of open. :)