| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1453
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | MacOS |
|---|
| Summary: | --post can be avoided on OSX 10.3 and beyond |
|---|
| Version: | 1.1-current |
|---|
| Created By: | wavexx |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v5627) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | wavexx
17:46 Sep 27, 2006 |
| Since 10.3 you can avoid "Rezzing" your stand-alone executable, with all the advantages this brings.
There's a documented API to bring the process into foreground, as demonstrated by the attached patch. For earlier versions, there's also an undocumented API (which I didn't bother to implement here).
The 10.3 check should also be propagated to configure, and expand --post to a no-op (however, this is not needed). | |
| |
| #2 | mike
06:49 Sep 28, 2006 |
| Not sure if we want to eliminate --post at this time, as some FLTK developers still support 10.2.x and earlier. I'm also not sure how this will interact with bundles, specifically for applications that support both a GUI and non-GUI mode (we don't want a dock icon to appear unless we open a window, right? :)
Anyways, will do a little testing to see if this change will have side-effects. | |
| |
| #3 | wavexx
07:11 Sep 28, 2006 |
| I'd push a little for the elimination of Rez if possible, as it removes the need of resource forks for stand-alone applications, which are deprecated as of OSX.
You are right about 10.2 and earlier. In this case I'd check for the current OSX version and proceed with the undocumented api. This would work as expected if one uses MACOSX_DEPLOYMENT_TARGET correctly without special fuss (since the undocumented api is being used by Apple's GLUT.framework as well as many other packages).
Some testing is indeed needed. I've added the change in fl_open_display for which I'm not sure of when it's called, but we may want to move that in some other point so, as you say, an application that doesn't call Fl::run doesn't create a dock icon.
I'm attaching a modified patch with the undocumented api as well. | |
| |
| #4 | christoph
03:00 Oct 26, 2006 |
| The problem with adding this call is that it will no longer be possible to set the LSBackgroundOnly property in info.plist of the application bundle. Thus I would vote against this suggestion.
The only reason to create a standalone executable versus an applictaion bundle that I can think of is for debugging.
I would suggest two points instead:
1) add a script flkt_bundle or so that takes an executable and creates an application bundle from it (with some defualt icon default settings in info.plist). This could also be a new option for fltk_confi(eg. --osxbundle).
2) Document this function in the FLTK docs as an alternative to adding the resource forks
Christoph | |
| |
| #5 | wavexx
08:50 Oct 26, 2006 |
| I read the documentation for LSBackgroundOnly, but I don't really get its purpose. Any example?
As for self-contained executables, my reason is simple: I have a set of applications using FLTK and a framework depending on them. Having stand-alone executables allows for the framework to have consistent paths across all the OSes without any usage/handling difference.
I guess this could be fixed by using proxy scripts and symlinks, but this seems overkill for an application that doesn't use any bundle data nor is carbon/cocoa based. Fluid is another practical example of the mixed-environment problems I'm talking about.
Even if I don't clearly grasp the purpose of LSBackgroundOnly, I would still prefer a way to allow Rez to be unnecessary, current behavior unchanged, and LSBackgroundOnly working. Maybe there's a way to detect such a setting and act accordingly instead? | |
| |
| #6 | wavexx
09:13 Oct 26, 2006 |
| Or better yet, detect if the current executable is bundled and, if it is, disable this handling (allowing standard behavior).
I didn't find any easy way to tell the difference using CFBundle* functions tough, as CFBundleGetMainBundle will return a valid reference also with unbundled apps. | |
| |
| #7 | christoph
10:47 Oct 26, 2006 |
| The LSBackgroundOnly flag is necessary when you embed an application within another application (CocoaDialog is a typical example). When this flag is not set, you will end with two icons for the application in the dock.
Another example is when the program shall not appear in the dock, but still have a GUI, e.g. a virtual desktop pager.
What about adding the hint to TransformProcessType in the FLTK docs as an alternative to setting the resource fork? | |
| |
| #8 | wavexx
11:28 Oct 26, 2006 |
| Clear enough, thanks.
A simple suggestion isn't enough because you have to enter conditional code in your programs to behave like other OSes for GUI handling, which is unacceptable in my opinion (GUI code should be source-compatible with a GUI toolkit).
Rez is a good solution currently, but we had some issues here in storing executables with resource forks as part of our archival system (unix centric), and since there's no real need for them I've been looking for alternatives. Removing the Rez step in the build process would also be very nice. Since I'm migrating several apps from GLUT to FLTK, I've suggested the way the GLUT.framework solves the problem.
Since you have more experience with Carbon/Cocoa than me, how do you consider checking if the current executable is bundled? Do you see potential side effects or have better suggestions? (even if this isn't going in the release, I would still be interested for our usage). | |
| |
| #9 | christoph
23:50 Oct 26, 2006 |
| > A simple suggestion isn't enough because you have to enter conditional
> code in your programs to behave like other OSes for GUI handling, which
> is unacceptable in my opinion (GUI code should be source-compatible with
> a GUI toolkit).
>
In my experience #ifdef __APPLE__ etc. always become necessary at some point because FLTK does not offer abstractions for all concepts (e.g. there is no abstraction for IPC with anonymous pipes) so that I always have two files os.[h|cpp] defining my own os specific functions. It is not much of a pain writing a function toforeground that you always call in your code and that you implement to do nothing on other platforms.
BTW, is there also an API function to make a program a windows application on windows? Or is this only possible with compiler flags? Where does this information go (I had always thought it would also set some resource forks)?
Moreover #ifdefs will become necessary when the application is more than a standalone executable, because additional application data are stored differently on different OSs. | |
| |
| #10 | wavexx
03:47 Oct 27, 2006 |
| Depending on where you place your ifdefs: everywhere you want, except in your application. I have some pretty impressive amount of code (350k lines) that runs on most POSIX systems an WIN32 without a single conditional. We've been using GLUT and POSIX IPC only. On WIN32, the only exception, we made use of POSIX wrappers so that our code would run unchanged. Endless advantages in terms of maintainability, unit testing, building... I'm not looking back, no matter how small the ifdef. The larger the project, the more important these things get.
As for the windows console, I'm aware of several functions to manipulate it (create one if you don't have it etc), but I never investigated those.
However, I think we've gone too far from the bug report.
I'm going to refine the patch to check for unbundled apps to fix this issue. Whether this is going to be integrated or not, the maintainer will decide. | |
| |
| #11 | wavexx
13:20 Nov 02, 2006 |
| Ok, I've refined the patch again.
Now the process is transformed only for unbundled apps and only when needed. When the app is bundled in any way (see Apple's technote 2015 about the details) the code is skipped.
I've tested this against LSBBackgroundOnly, OSX 1.2, and some combinations. | |
| |
| #12 | matt
07:34 Jan 20, 2007 |
| Thanks for this great patch and the interesting discussion with it. I learned a lot and I wish I had know about this in 10.1. It would have saved me a lot of angry support calls of users that used the UNix "cp" to move around executables (which back then was not fork-aware - sigh).
Anyway, I took the last patch and moved it into the SVN. I do not want to renove the rousource fork managment in the Makfile just yet, but one day it'll go ;-) (and I'll burn it and stomp on it). | |
[ Return to Bugs & Features ]
|
| |
