OSX

[Mike Lobanovsky]

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,

[John]

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.

[Mike Lobanovsky]

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.

[John]

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.

[Mike Lobanovsky]

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.

[John]

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. 

[AIR]

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.

[AIR]

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.

[John]

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.

[AIR]

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.

[John]

After reading that, you'll understand WHY you don't normally do the GUI in code.

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. 

[Mike Lobanovsky]

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.

[AIR]

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.

[John]

Damn it's good to see you posting again. I thought you were dead. 

[Mike Lobanovsky]

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?