[Openmcl-devel] startup 'terminal' window

[Alexander Repenning]

I assume that Phil means that there should be a way of getting rid of  
the Listener. In the MCL based version of AgentSheets we have a end  
user / developer switch (only available through a key file). In end  
user mode you get:

- only application menus (no List tools etc)
- no listener
- all error and warning wrapped up in standard alerts with some some  
syntactic clean up
- disabled debugging tools, i.e., not backtrace etc.

If you want to deploy an app this is pretty important. End users  
really do not want to see or interact with listeners.

Alex


On Dec 23, 2008, at 2:54 PM, Gary Byers wrote:

> I'm afraid that I don't really have much of a model of how your
> application is structured, of what behavior you're seeing and of
> what behavior you want to see, or of what any of this has to do
> with CCL.
>
> Besides noting that Windows, X environments under Linux, and OSX
> all have different views of:
>
> - whether there's a distinction between "console applications"
> and "GUI applications" (and, if so, how that distinction is
> maintained)
> - (related) what it means for an application to be associated
> with a console or terminal window
> - what happens (in general and in specific cases) when someone
> opens an icon in a desktop environment,
>
> it's not clear what to say that could be useful.
>
> On OSX, must things that you'd think of as GUI applications are
> packaged as application bundles (special directories whose extension
> is ".app" and whose contents follow certain conventions.)  If you
> double-click on "foo.app"'s icon in the Finder, the application
> starts up, with its own icon in the Dock and its own menubar; the
> new process's standard input comes from the null device and output
> goes to some logging device.  If you execute "open foo.app" in a
> shell or shell script, essentially the same things (includung
> the I/O redirection) happen as when the file is opened in the Finder.
> (The "open" in that case is just "/usr/bin/open", which basically
> just uses the same system services that the Finder uses to open
> files and URLs that it receives as command-line arguments.)
>
> The actual executable involved in running "foo.app" is nside the
> Contents/MacOS subdirectory of the .app bundle.  (The exectuable
> file is often the only file in that directory and its name often
> matches the bundle directory's name without the ".app"; its name
> is specified as the value of some XML key in Contents/Info.plist.)
> If you run the executable directly (in the shell or a shell script):
>
> shell> /path/to/foo.app/Contents/MacOS/foo
>
> then most things will likely be the same as they would be if the
> app was launched via "open" or the Finder; one notable difference
> is that the I/O redirection won't have happened and the process
> will remain connected to the same standard I/O streams as the
> parent (shell) uses (unless of course it's invoked with some
> sort of explicit redirection.)
>
> If you double-click on a non-.app executable file in the Finder,
> the Finder will generally open a Terminal.app window and run
> the executable "in that window" (e.g., with its standard input
> coming from and standard output going to that Terminal window.)
> It seems to do this via a technique not obviously different from
> writing a .cmd file somewhere and then opening that file.
>
> If you select an application bundle in the Finder and right-click
> (or ctrl-click) on it, you'll get a menu with an option named
> "Show Package Contents" (or something similar.)  If you select
> that option and navigate to the executable inside Contents/MacOS,
> you'll get similar behavior.
>
> Again, I can't tell from your message what application is not
> (accidentally or intentionally) display a console/terminal
> window or what CCL has to do with this, and I don't know whether
> any of the above is directly useful.  A program's behavior in this
> regard has a lot to do with how it's invoked, and this may be
> more true on OSX than on other platforms.
>
>
>
>
> On Mon, 22 Dec 2008, Phil Armitage wrote:
>
>> Hi,
>>
>> I distribute my GUI (LTK) application on three platforms (Mac OS X,
>> Windows and Linux) as either:
>>
>> 1) a directory containing a Lisp compiler + my code + required  
>> systems
>> + a shell script to start it all up
>> 2) a platform specific binary.
>>
>> Either way, when I start the application by double-clicking I get the
>> GUI window *and* a 'terminal' window with the output from the Lisp
>> system. On Windows (currently using CLISP or SBCL) I can hide this
>> second window (actually it's really the first window) by having the
>> user run a small C program which starts the actual binary before
>> hiding itself from view. On Linux, this doesn't happen at all.
>>
>> Is there anything I can do with CCL on OS X? I've looked at the
>> available compiler options but can see nothing related to this and
>> I've tried fiddling around with .command files, .term files and even
>> Apple Script but all to no avail. As things stand, I get complaints
>> from users about this so any help would be much appreciated!
>>
>> Thanks,
>>
>> -- 
>> Phil Armitage
>> http://phil.nullable.eu/
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20081223/c3c625cd/attachment.htm>