[Openmcl-devel] IDE build-app interface?

[Paul Krueger]

Sorry for the long email below. If you're not interested in building  
stand-alone Cocoa apps delete now.

For my next contrib Cocoa project I've been thinking about doing an  
interface to the build-application code and generally adding  
facilities to support the evolution of an application from one that  
runs under the IDE to one that runs stand-alone. Is anyone already  
working on functionality like this? I don't want to duplicate efforts  
if this is already underway. I'd be happy to help out if work is  
underway and help is needed.

If nobody is already doing it, then I'll take it on. I have my own  
initial vision about how this might look, but I'd like to solicit  
input from anyone who has thoughts about what this should do.

Some initial design considerations ...

It seems to me that the path one would take from debugging with the  
IDE to having a stand-alone app depends on how much overlap or  
conflict exists between the app and the IDE. Areas where overlap/ 
conflict might exist include:

1. Menus ... Although it's possible to add new menus and/or menuitems  
to CCL's default set when running under the IDE, it might be better to  
provide functionality that toggles back and forth between the IDE's  
set of menus and a set provided via a developer NIB while debugging  
under the IDE. Then that NIB could be made the default for a stand- 
alone app. I can imagine functions that would show one set or the  
other or both side-by-side and change the viewable set(s) on the fly.  
The build interface should support selection of these options.

2. Application and App delegate classes ... I don't believe there is  
any way to substitute different versions of these at runtime. So that  
means that to really test an alternate class that you define you'd  
probably have to build a stand-alone app with the new classes in  
place. In some cases it might be possible to subclass the lisp- 
application and/or lisp-application-delegate classes to build an app  
that has both the IDE functionality and whatever new functionality is  
needed. The build interface should support the specification of  
application and app delegate classes. Some validity checking should be  
done to assure that if IDE resources are included, then the app and  
app delegate classes are sub-classes of their IDE counterparts.

3. Document controller ... The app delegate for the CCL IDE  
initializes a hemlock-document-controller at startup. Custom apps are  
likely to want to provide their own document controller. Making a  
subclass of hemlock-document-controller might be possible, but some  
changes to the app delegate would also be required to make sure that  
the new subclass is the one created when the app is initialized. The  
interface should also make it easy to add new document types, so the  
controller knows what class should manage each type.

4. Init file ... Some apps may want to load and use normal user- 
specified init files and some may not. Some may want two different  
init files loaded. The interface should allow specification of desired  
behavior.

5. Application preferences ... May want to use IDE prefs or user- 
defined or both. Build user interface should permit specification.  
Maybe most of this just falls out of what menus are used.

For my existing interface projects I have studiously avoided doing  
anything that might require changes to IDE functionality, but I think  
a case can be made for modifying the IDE in a way that permits easier  
extension using developer-defined subclasses. The idea would be to  
permit a path that evolves from:
1. Adding and testing functionality under an unmodified IDE (like my  
existing contrib projects) to
2. Building a stand-alone app that has substantially all of the IDE  
capabilities (typically for debugging) to
3. Building a stand-alone app that has little or no IDE functionality
I've only been looking at the existing code for a few days, so I'm not  
exactly sure yet where modifications would have to be made, but I'm  
reasonably confident that something like this is possible with modest  
modifications to existing IDE classes.

I also want to strengthen the integration between CCL and Interface  
Builder by automatically creating class descriptions (of the sort that  
can be read into Interface Builder) for specified Lisp classes (that  
must inherit from Objective-C of course). This would make it easier to  
use and configure such classes when designing interfaces. I'd also  
like to trigger IB to actually load these (like Xcode does) if I can  
figure out how to do it. As near as I can tell there aren't any Apple  
Events supported by IB that would make that easy to do. There is a  
menu item in IB ("Read Class Files ...") that users can select to load  
class descriptions from a path they choose. So in the worst case the  
process would be to create the descriptions in Lisp and the developer  
would have to choose that menu item in IB and choose the right path.   
I'd prefer to make that loading automatic if possible. I'm not exactly  
an Apple Events / Applescript expert (yet), but if somebody can  
explain how the Xcode/IB interaction works or suggest a way to  
automate the menu item selection AND path specification, then maybe I  
could find a way to make this work automatically from the IDE as well.

I've also attached a rough first cut at what a build interface window  
might look like in the IDE. I expect that would change as the process  
is refined.

Comments and suggestions appreciated.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.jpg
Type: image/jpeg
Size: 57180 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100430/af3592ed/attachment.jpg>
-------------- next part --------------