[Openmcl-devel] IDE build-app interface?

Fri Apr 30 10:26:37 PDT 2010

As long as you're collecting a wish list.... Currently, hemlock is only
available as a window.  It would be really great to have it available as a
view, i.e. something that could be added to application windows.

On Fri, Apr 30, 2010 at 10:55 AM, Paul Krueger <plkrueger at comcast.net>wrote:

> 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
>
>
>
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100430/0a864fe3/attachment.htm>