<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Paul,<div><br></div><div>I think the two approaches, while being pretty different, could be quite complementary. I would be interested to hear about experience of using NIB files on Cocotron. It must work to some degree. Cocotron examples are using NIB files. Probably, for now, the largest overlap in interest would be the error handling. Perhaps we should discuss typical error scenarios and how to possibly deal with them.</div><div><br></div><div>all the best, Alex</div><div><br></div><div><br></div><div><br><div><div>On Apr 30, 2010, at 1:33 PM, Paul Krueger wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Alex,<div><br></div><div>I've previously looked at your approach and while I understand what you're doing, what I've already put in my contrib directory seems to me to have little overlap with your work. I'm consciously taking an approach that mirrors Apple's Model/View/Controller paradigm; using Interface Builder for the View part of this and Lisp for the model (data) and controller parts (whenever possible). My objective is to open up all the capabilities of Cocoa to Lisp developers in a way that lets them fairly directly apply anything they can learn from the mountains of existing Cocoa documentation. I'm explicitly NOT trying to provide a distinctly different interface development language (Lisp or XML or anything else) that has to undergo a translation to Cocoa. Nor am I trying to create any sort of layer intended to hide Cocoa complexity from developers. Cocoa itself provides many sorts of concepts and tools intended to make things easier for developers. I just want to make Cocoa usable from Lisp as directly as possible. To that end, the tutorial in my contrib directory is an attempt to teach Cocoa concepts in an incremental fashion to Lisp developers. Some of the things I'm proposing now would have made that a bit easier right from the start, but c'est la vie. I think that perhaps we just have different target audiences for our work.</div><div><br></div><div>I'd love to see what I've already done get ported to Cocotron, but that isn't on my immediate agenda. That said, if you have any sort of documentation that describes what sorts of limitations you found or how you overcame various obstacles, I'd find that pretty interesting. It might inform some of the design choices I make now. I would also be happy to cooperate with anyone who wanted to convert anything I've done to Cocotron. </div><div><br></div><div>What you've done with error handling sounds quite interesting and at some point I will probably want to look at that. While this isn't my immediate priority, if what you have already done could be applied outside of your XML context I would love to see any documentation or code that you are willing to share. </div><div><br></div><div>Resource bundling is a big part of what the existing CCL build-application function does. My proposed interface mostly reflects the parameters of that function with a few extensions that I think are needed. I expect that many or most of the fields will have reasonable defaults and others will provide a limited set of options, so the learning curve shouldn't be too bad. But ultimately I want to make any sort of allowable customization possible. All of this is, I hope, consistent with an approach that enables full customization for complex designs, but requires relatively little beyond provided defaults for simple ones.</div><div><br></div><div>If you still think there is enough overlap between what we're doing to justify more conversation, let me know.</div><div><br></div><div>Regards,</div><div><br></div><div>Paul</div><div><br></div><div><br><div><div>On Apr 30, 2010, at 12:48 PM, Alexander Repenning wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Paul,</div><div><br></div><div>looks like very exciting stuff.</div><div><br></div><div>Short answer, yes we are already working on this but love to have some help. This project is partially funded by NSF. An important aspect is for it to work on Macs and PCs. Some older info here: <a href="http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6WMM-4W4TY0B-1&_user=918210&_coverDate=08%2F31%2F2009&_rdoc=1&_fmt=high&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1317856703&_rerunOrigin=google&_acct=C000047944&_version=1&_urlVersion=0&_userid=918210&md5=6f86cf86efad1fc5989c01d9dac129fd">http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6WMM-4W4TY0B-1&_user=918210&_coverDate=08%2F31%2F2009&_rdoc=1&_fmt=high&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1317856703&_rerunOrigin=google&_acct=C000047944&_version=1&_urlVersion=0&_userid=918210&md5=6f86cf86efad1fc5989c01d9dac129fd</a></div><div><br></div><div>Some issues of importance:</div><div><br></div><div>- needs to be cross platform via Cocotron. Cocotron can deal with nib files but is missing some or not completely implementing other classes. I am just guessing that this could be a problem. In many cases we need to create our classes to compensate for such holes. For the most part we use the XMLisp stuff instead of nib files to create windows and dialogs. Works pretty well. </div><div><br></div><div>- error handling: we cannot allow the end-user version to dive into the alt console. This means that we need to have wrappers trying to remedy things as much as possible and only really crash if there is no other option. This was a lot of work to get working in the MCL version at may be even trickier with the native thread model of CCL.</div><div><br></div><div>- resource bundeling: we need and have scripts to wrap up complete versions of an app including all the nib, plist, resources, sounds, .... files, an example is in here: <a href="http://code.google.com/p/xmlisp/source/browse/trunk/XMLisp/sources/XMLisp-init.lisp">http://code.google.com/p/xmlisp/source/browse/trunk/XMLisp/sources/XMLisp-init.lisp</a></div><div><br></div><div>- App building: Your interface looks nice but at least for our apps we usually need just a build function that does it all without any need for users to interact. In other words for us this is one of the few cases where were prefer NOT to have a GUI. We run build-agentcubes and all the magic happens. </div><div><br></div><div>At any rate, lets talk and explore overlap.</div><div><br></div><div>all the best, Alex</div><div><br></div><div><br></div><br><div><div>On Apr 30, 2010, at 8:55 AM, Paul Krueger wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Sorry for the long email below. If you're not interested in building stand-alone Cocoa apps delete now.<br><br>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.<br><br>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.<br><br>Some initial design considerations ...<br><br>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:<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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:<br>1. Adding and testing functionality under an unmodified IDE (like my existing contrib projects) to<br>2. Building a stand-alone app that has substantially all of the IDE capabilities (typically for debugging) to<br>3. Building a stand-alone app that has little or no IDE functionality<br>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.<br><br>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.<br><br>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.<br><br>Comments and suggestions appreciated.<br><br>Paul<br><br><span><pastedGraphic.jpg></span><br><br><br>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br><a href="http://clozure.com/mailman/listinfo/openmcl-devel">http://clozure.com/mailman/listinfo/openmcl-devel</a><br></div></blockquote></div><br><div> <span class="Apple-style-span" style="font-size: 12px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Prof. Alexander Repenning</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="khtml-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">University of Colorado</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Computer Science Department</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Boulder, CO 80309-430</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="khtml-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">vCard: <a href="http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf">http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf</a></font></div><br class="Apple-interchange-newline"></span></span></span> </div> <br></div></blockquote></div><br></div></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Prof. Alexander Repenning</font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><br class="khtml-block-placeholder"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px">University of Colorado</p><p style="margin: 0.0px 0.0px 0.0px 0.0px">Computer Science Department</p><p style="margin: 0.0px 0.0px 0.0px 0.0px">Boulder, CO 80309-430</p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><br class="khtml-block-placeholder"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">vCard: <a href="http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf">http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf</a></font></p><br class="Apple-interchange-newline"></span></span></span></span>
</div>
<br></div></body></html>