Re: app-bundle vs. regular/"BSD utility" executables : what differences are there still?
On Tuesday January 05 2016 10:29:41 Jeremy Huddleston Sequoia wrote: >It's possible for a standalone executable to have an Info.plist. It is >embedded in the executable in an __info_plist section. This can be done by >the CREATE_INFOPLIST_SECTION_IN_BINARY Xcode build setting or by creating an >__info_plist section manually at link time if not using Xcode >(-Wl,-sectcreate,__TEXT,__info_plist,/path/to/my/Info.plist). I've tried to read up on this way of "bundling" an Info.plist, but all I've found to date is focused on info dicts that are intended only (chiefly?) for allowing an executable to be code-signed. I haven't found any discussion of the elements that are supported. It seems safe to assume that a list of document types will simply be ignored, though maybe not the references it makes to document icons. The bundle icon idem: is that key ignored when present in an embedded Info.plist, or if not, where is the icon expected to be found? All this because there is a CMake macro (in the ECM, "Extra CMake Modules") that makes it trivial to switch the target between an app bundle and a traditional executable. The app bundle gets a standard Info.plist with the proper key/value pairs (including the app icon if one is defined in the CMake file). It'd probably be easiest if that plist can be embedded. Thanks, René ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: app-bundle vs. regular/"BSD utility" executables : what differences are there still?
> On Jan 5, 2016, at 11:35, René J.V. Bertin wrote: > > On Tuesday January 05 2016 10:29:41 Jeremy Huddleston Sequoia wrote: > > Thanks! > >> There are really two main difference between the two cases: >> 1) The app bundles have an inherent main bundle (ie: [NSBundle mainBundle]). > > But CFBundleGetMainBundle() does return something equivalent for non-bundled > applications... It's set to the directory that contains the main executable. I'm not sure if that is a contract or just a behavior quirk. I don't see it documented as such, so I wouldn't rely on that behavior. >> 2) Apps are (usually) launched by LaunchServices. You can exec them >> directly, but that is not the preferred way to do it (and may not always >> work in the future). > > Oh? >> >> It's certainly possible for processes to draw GUI elements without being >> bundled, but it's less trivial. > > That's the impression I had, but I haven't been able to confirm that > recently, other than a subtle difference if you invoke the bundle exec via > its full path or via a symlink. > Interaction with the elements can be more tricky; Qt5 applications I exec > directly often do not show the menubar immediately until I cycle the > foreground application. I suspect this has to do with the fact that Qt5 calls > [NSApplication activateIgnoringOtherApps:] quite early (too early) during > initialisation. >> >> It's possible for a standalone executable to have an Info.plist. It is >> embedded in the executable in an __info_plist section. This can be done by >> the CREATE_INFOPLIST_SECTION_IN_BINARY Xcode build setting or by creating an >> __info_plist section manually at link time if not using Xcode >> (-Wl,-sectcreate,__TEXT,__info_plist,/path/to/my/Info.plist). > > I usually use CFBundleGetInfoDictionary() and CFDictionarySetValue(), Yeah, don't do that. ;) > but embedding the infodict like above is certainly easier once it contains > more than 1 or 2 elements! >> As far as spawning processes in general, please don't use system() or >> fork()/exec(). Please use the posix_spawn syscall instead as it is much >> cleaner and has less overhead. > > I'm not really familiar with that API, but a quick look suggests that the > variant for spawning in "non-detached" fashion (spawnfd) is missing, correct? Please elaborate. > >> The open utility is basically a CLI to LSOpenURLsWithRole(). It does not >> exec or spawn anything. It just calls into LSOpenURLsWithRole(). > > Hmm, ok. I once wrote an alternative, but I cannot remember exactly why. > Looks like I only simplified the calling syntax (`osxlaunch [-W] command > [arguments]`). > > > R. > ___ > macports-users mailing list > macports-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: app-bundle vs. regular/"BSD utility" executables : what differences are there still?
On Tuesday January 05 2016 10:29:41 Jeremy Huddleston Sequoia wrote: Thanks! > There are really two main difference between the two cases: > 1) The app bundles have an inherent main bundle (ie: [NSBundle mainBundle]). But CFBundleGetMainBundle() does return something equivalent for non-bundled applications... > 2) Apps are (usually) launched by LaunchServices. You can exec them > directly, but that is not the preferred way to do it (and may not always work > in the future). Oh? > > It's certainly possible for processes to draw GUI elements without being > bundled, but it's less trivial. That's the impression I had, but I haven't been able to confirm that recently, other than a subtle difference if you invoke the bundle exec via its full path or via a symlink. Interaction with the elements can be more tricky; Qt5 applications I exec directly often do not show the menubar immediately until I cycle the foreground application. I suspect this has to do with the fact that Qt5 calls [NSApplication activateIgnoringOtherApps:] quite early (too early) during initialisation. > > It's possible for a standalone executable to have an Info.plist. It is > embedded in the executable in an __info_plist section. This can be done by > the CREATE_INFOPLIST_SECTION_IN_BINARY Xcode build setting or by creating an > __info_plist section manually at link time if not using Xcode > (-Wl,-sectcreate,__TEXT,__info_plist,/path/to/my/Info.plist). I usually use CFBundleGetInfoDictionary() and CFDictionarySetValue(), but embedding the infodict like above is certainly easier once it contains more than 1 or 2 elements! > > As far as spawning processes in general, please don't use system() or > fork()/exec(). Please use the posix_spawn syscall instead as it is much > cleaner and has less overhead. I'm not really familiar with that API, but a quick look suggests that the variant for spawning in "non-detached" fashion (spawnfd) is missing, correct? > The open utility is basically a CLI to LSOpenURLsWithRole(). It does not > exec or spawn anything. It just calls into LSOpenURLsWithRole(). Hmm, ok. I once wrote an alternative, but I cannot remember exactly why. Looks like I only simplified the calling syntax (`osxlaunch [-W] command [arguments]`). R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: app-bundle vs. regular/"BSD utility" executables : what differences are there still?
There are really two main difference between the two cases:
1) The app bundles have an inherent main bundle (ie: [NSBundle mainBundle]).
2) Apps are (usually) launched by LaunchServices. You can exec them
directly, but that is not the preferred way to do it (and may not always work
in the future).
It's certainly possible for processes to draw GUI elements without being
bundled, but it's less trivial.
It's possible for a standalone executable to have an Info.plist. It is
embedded in the executable in an __info_plist section. This can be done by the
CREATE_INFOPLIST_SECTION_IN_BINARY Xcode build setting or by creating an
__info_plist section manually at link time if not using Xcode
(-Wl,-sectcreate,__TEXT,__info_plist,/path/to/my/Info.plist).
As far as spawning processes in general, please don't use system() or
fork()/exec(). Please use the posix_spawn syscall instead as it is much
cleaner and has less overhead.
The open utility is basically a CLI to LSOpenURLsWithRole(). It does not exec
or spawn anything. It just calls into LSOpenURLsWithRole().
> On Jan 5, 2016, at 02:58, René J.V. Bertin wrote:
>
> Hi,
>
> This is a rather technical question that in itself is only indirectly related
> to MacPorts:
>
> What are the current differences in terms of what applications can or cannot
> do if they're built as traditional executable files ("BSD Utilities" in Apple
> speak) vs. as/in an app bundle?
> From what I remember, it used to be pretty clear-cut: any application wanting
> to put up a usable GUI basically had to be built as an app bundle ... unless
> you were called Adobe Illustrator (or comparable) in which case you could be
> built like a PEF executable or something of the sort.
>
> Evidently a "BSD Utility" cannot have an Info.plist, but there are ways to
> set up that Info Dictionary programmatically (I've been doing that with the
> LSUIElement flag in numerous Qt/KDE daemons). Other than that, I'm not
> noticing any difference in the behaviour of applications built either the one
> or the other way, at least not when I launch them from a terminal or
> fork()/exec() .
>
> I'm asking in the context of designing a cross-platform "launch-a-process"
> function which provides the most natural opening behaviour of the started
> application. In particular, something that does not cause the new application
> to open its windows behind those of the current process, so unlike what
> happens when you use system() or fork()/exec() to start an application on OS
> X (instead of LaunchServices).
>
> From what I can tell, one needs to use LaunchServices in order to start an
> application "A" the way it would start from the Finder, i.e. in the front
> layer unless you bring another application to the front after starting
> application "A".
>
> However, LaunchServices will not launch all applications directly; it
> certainly uses Terminal.app as a delegate when starting a shell script. I am
> less sure about GUI applications built as BSD utilities; I have the
> impression that the "open" command will usually launch those directly ... but
> then again that command probably doesn't use LaunchServices in its most basic
> form.
> This is probably the main question I'm looking to see answered: when/how can
> I use LaunchServices so it doesn't use a delegate application like
> Terminal.app ?
>
> A related question: I've managed to write an AppleScript that brings a
> started application to the foreground from the calling application, using the
> "System Events" library. What SDK would I be looking for to see if I can do
> the same without using AppleScript?
>
> Thanks,
> René
smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
app-bundle vs. regular/"BSD utility" executables : what differences are there still?
Hi,
This is a rather technical question that in itself is only indirectly related
to MacPorts:
What are the current differences in terms of what applications can or cannot do
if they're built as traditional executable files ("BSD Utilities" in Apple
speak) vs. as/in an app bundle?
>From what I remember, it used to be pretty clear-cut: any application wanting
>to put up a usable GUI basically had to be built as an app bundle ... unless
>you were called Adobe Illustrator (or comparable) in which case you could be
>built like a PEF executable or something of the sort.
Evidently a "BSD Utility" cannot have an Info.plist, but there are ways to set
up that Info Dictionary programmatically (I've been doing that with the
LSUIElement flag in numerous Qt/KDE daemons). Other than that, I'm not noticing
any difference in the behaviour of applications built either the one or the
other way, at least not when I launch them from a terminal or fork()/exec() .
I'm asking in the context of designing a cross-platform "launch-a-process"
function which provides the most natural opening behaviour of the started
application. In particular, something that does not cause the new application
to open its windows behind those of the current process, so unlike what happens
when you use system() or fork()/exec() to start an application on OS X (instead
of LaunchServices).
>From what I can tell, one needs to use LaunchServices in order to start an
>application "A" the way it would start from the Finder, i.e. in the front
>layer unless you bring another application to the front after starting
>application "A".
However, LaunchServices will not launch all applications directly; it certainly
uses Terminal.app as a delegate when starting a shell script. I am less sure
about GUI applications built as BSD utilities; I have the impression that the
"open" command will usually launch those directly ... but then again that
command probably doesn't use LaunchServices in its most basic form.
This is probably the main question I'm looking to see answered: when/how can I
use LaunchServices so it doesn't use a delegate application like Terminal.app ?
A related question: I've managed to write an AppleScript that brings a started
application to the foreground from the calling application, using the "System
Events" library. What SDK would I be looking for to see if I can do the same
without using AppleScript?
Thanks,
René
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
