Completely puzzled vis-a-vis Carbon and Unix executables
nikkoara
some obscure Apple docs describing exactly what I don't understand:
The following code:
#include <assert.h>
#include <Carbon/Carbon.h>
int main ()
{
WindowClass wc = kDocumentWindowClass;
WindowAttributes wa =
kWindowCloseBoxAttribute |
kWindowCollapseBoxAttribute |
kWindowResizableAttribute |
kWindowCompositingAttribute |
kWindowStandardHandlerAttribute |
kWindowLiveResizeAttribute |
kWindowNoConstrainAttribute;
Rect r = { 0, 0, 300, 300 };
WindowRef wr;
assert (0 == CreateNewWindow (wc, wa, &r, &wr));
ShowWindow (wr);
RepositionWindow (wr, 0, kWindowCascadeOnMainScreen);
RunApplicationEventLoop ();
DisposeWindow (wr);
return 0;
}
when built and run like:
$ g++ -g t.cpp -o t && ./t
creates an immobile, unfocused window behind the terminal window which
I cannot bring to front or resize.
If I paste this code into an XCode "simple Carbon window" project (i.e.
into main.c) then it works as expected: it gives me a resizable,
movable, focusable :-) window. But then, the end-result of building the
XCode project is a directory structure with some obscure resources and
an executable tucked underneath.
What am I missing here??? I have a suspicion that creating a window via
a [so-called] Unix executable is not possible with Darwin. Is that
true?
TIA.
Sherm Pendley
> when built and run like:
>
> $ g++ -g t.cpp -o t && ./t
>
> creates an immobile, unfocused window behind the terminal window which
> I cannot bring to front or resize.
>
> If I paste this code into an XCode "simple Carbon window" project (i.e.
> into main.c) then it works as expected: it gives me a resizable,
> movable, focusable :-) window. But then, the end-result of building the
> XCode project is a directory structure with some obscure resources and
> an executable tucked underneath.
>
> What am I missing here?
You're missing the fact that the contents of a .app bundle are neither
obscure nor optional - they're well-documented and quite necessary.
For details, have a look at:
<http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/index.html>
AKA:
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Michael Ash
>
> creates an immobile, unfocused window behind the terminal window which
> I cannot bring to front or resize.
>
> If I paste this code into an XCode "simple Carbon window" project (i.e.
> into main.c) then it works as expected: it gives me a resizable,
> movable, focusable :-) window. But then, the end-result of building the
> XCode project is a directory structure with some obscure resources and
> an executable tucked underneath.
>
> What am I missing here??? I have a suspicion that creating a window via
> a [so-called] Unix executable is not possible with Darwin. Is that
> true?
If you really want to do this, you can use TransformProcessType. However,
it is highly recommended to simply make a real .app instead.
--
Michael Ash
Rogue Amoeba Software
nikkoara
I appreciate you pointing me in the right direction with respect to
understanding the anatomy of the bundle but a cursory look at the docs
does not reveal *why* the bundle is functional but not a standalone
UNIX executable. After all my program does not need a nib file, nor
does it need string resources, sounds, images, etc. (or so I think
after my testing) It is self sufficient and it is build with a
compiler which produces a native executable and all necessary libraries
are linked correctly.
While a bundle is an efficient way to store in a single place data
associated with one's program, what is it that makes a bundle-d program
work?
TIA.
nikkoara
ported variants and because of the UNIX heritage I expected (naive me)
to be able to build on Darwin out of the box.
Sherm Pendley
> I appreciate you pointing me in the right direction with respect to
> understanding the anatomy of the bundle but a cursory look at the docs
> does not reveal *why* the bundle is functional but not a standalone
> UNIX executable.
Does it really matter why Apple chose to go that way? Whether you and I
agree with their reasons or not, the choice is already made, and we need
to write for the OS as it is, not as we think it should be.
If supporting unbundled executable files is important to you, then by all
means file a feature request using Apple's bug reporter:
> After all my program does not need a nib file, nor
> does it need string resources, sounds, images, etc.
Then don't include them. IIRC, the only strict requirement is the executable
itself and the plist - and the plist can be pared down to a bare minimum
of app name and identifier.
Note that the bundle is the requirement here - not Xcode. You can just as
easily create a .app bundle with a make file.
Sherm Pendley
> Not really an option right now... The project is using autotools on all
The use of autotools doesn't preclude the end result being a bundle. I use
autotools myself, producing a framework bundle using a make file. An .app
bundle would be no more difficult.
> ported variants and because of the UNIX heritage I expected (naive me)
> to be able to build on Darwin out of the box.
Note that command-line and X11 apps do *not* need .app bundles. The only
apps that require them are those that expect to use the native GUI.
Michael Ash
> Not really an option right now... The project is using autotools on all
> ported variants and because of the UNIX heritage I expected (naive me)
> to be able to build on Darwin out of the box.
Please don't top post.
You're already using tons of OS-specific calls to display a window. You
can't add *one more* to get your app to interact properly with the system?
nikkoara
Sorry, I meant creating an .app via an XCode project is not an option.
As Sherm was pointing out earlier, creating a bundle via autotools is
most probably the path I would take.
Thanks.
nikkoara
> "nikkoara" <nikk...@gmail.com> writes:
>
> > Not really an option right now... The project is using autotools on all
>
> The use of autotools doesn't preclude the end result being a bundle. I use
> autotools myself, producing a framework bundle using a make file. An .app
> bundle would be no more difficult.
Postprocessing after building the executables or did you somehow
integrate it in autotools?
>
> > ported variants and because of the UNIX heritage I expected (naive me)
> > to be able to build on Darwin out of the box.
>
> Note that command-line and X11 apps do *not* need .app bundles. The only
> apps that require them are those that expect to use the native GUI.
It's an arbitrary discrimination from my point of view and brings
unnecessary complications to a development environment. <sigh>
Thanks.
nikkoara
That did the trick. I still don't see the connection between the call
and the effect though. The docs say:
"You can use this call to transform a background-only application into
a foreground application."
and indeed the only constant which can be passed to it is
kProcessTransformToForegroundApplication.
Does this mean that I have created a background-only application in my
test?
Anyway, thanks for the help!
Michael Ash
>>
>> Note that command-line and X11 apps do *not* need .app bundles. The only
>> apps that require them are those that expect to use the native GUI.
>
> It's an arbitrary discrimination from my point of view and brings
> unnecessary complications to a development environment. <sigh>
But it's not arbitrary discrimination from the point of view of the user.
Unbundled executables will open a Terminal window when double-clicked, and
will dump their output to that window instead of to the Console. Closing
the window or quitting Terminal will kill the application. This is all
deeply unexpected behavior for your typical Mac user.
When given the choice between making life easier for users or making life
easier for developers, Apple generally sides with the users, and I have to
say that I agree with them in doing so.
Michael Ash
I think that the documentation for this call is just really bad. It didn't
even exist until recently. Before that the only way to accomplish this was
to use private functions that weren't published anywhere.
The basic goal is to get your application hooked into LaunchServices, the
WindowServer, and the Dock so that it's treated like a normal application.
Launching a .app does this automatically, and TransformProcessType does
this manually.
I truly have no idea how you would discover this call if someone didn't
tell you about it, though.
Sherm Pendley
> Sherm Pendley wrote:
>> "nikkoara" <nikk...@gmail.com> writes:
>>
>> > Not really an option right now... The project is using autotools on all
>>
>> The use of autotools doesn't preclude the end result being a bundle. I use
>> autotools myself, producing a framework bundle using a make file. An .app
>> bundle would be no more difficult.
>
> Postprocessing after building the executables or did you somehow
> integrate it in autotools?
The executable is built directly in-place, in the appropriate subdirectory
within the .framework bundle. There are also targets to create any pieces of
the directory tree that might be missing.
Feel free to have a look - the make file is freely available as part of my
CamelBones project, listed in my .sig. It also contains an incantation to
handle a --with-sdk configure option, and will build a Universal Binary if
the appropriate SDK is selected.
Ben Artin
"nikkoara" <nikk...@gmail.com> wrote:
> While a bundle is an efficient way to store in a single place data
> associated with one's program, what is it that makes a bundle-d program
> work?
The contents of the Info.plist file in the bundle give the OS all the metadata
it needs to do the right thing with your executable. You can embed an Info.plist
into your executable; see the instructions at the bottom of
<http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Artic
les/ConfigFiles.html>
Hth,
Ben
--
If this message helped you, consider buying an item
from my wish list: <http://artins.org/ben/wishlist>
I changed my name: <http://periodic-kingdom.org/People/NameChange.php>