[Openmcl-devel] prompt-for-file (embarrassing question)

[Paul Krueger]

I’ve been kind of waiting to see where this conversation went. I’m yet another old-timer. I’m so old that I remember doing user interfaces by sending text strings to CRT monitors and drawing graphs by printing characters across multiple lines on paper. So I was an early adopter of MCL which allowed some very cool interface development.

The problem is that as the display hardware became more and more sophisticated and as graphical designs evolved to take advantage of what the hardware could do, the software api’s became increasingly more complex as well. The look and feel of platforms became a proprietary advantage and the interpretation of copyright laws meant that any chance for commonality across all platforms was doomed.

That hasn’t stopped various efforts to build a universal api that was platform-agnostic. The advantages of that for developers is obvious. But even with many supporters for some of those, they have never managed to maintain momentum over time. Platform sellers like Apple developed more and more proprietary development frameworks and tools which lock a developer into their way of doing things. That doesn’t entirely prevent the development of a cross-platform GUI, but anyone making the attempt must constantly chase a moving target. And there are often just fundamentally different ways to interact with GUI API’s for different platforms that make it difficult to write a single application for multiple platform API’s.

It’s not the language features that determine what sort of GUI you can develop, its the GUI API and the tools that are provided to access that API that decide what GUI programming looks like. You can blame CL or CCL if you like, but the reality is that you can do pretty much any cocoa programming that you want to do in CCL. Of course Apple has made that more and more difficult to do with any language other than those they officially support. If the complexity is daunting, blame Apple, but recognize that they’re just trying to provide the highest level of GUI capability to professional developers because that’s what is ultimately driving their sales.

The problem with any platform-agnostic GUI development API (CLIM, TCL/TK, X11, Qt, etc.) is that they almost never support the latest and greatest features of the major platforms. What you develop using them just never looks or feels quite right to a native user. And since those platforms are constantly moving targets, keeping up with the changes is a herculean task that nobody will maintain for very long. You’d need a large, committed support community to have a chance and to the best of my knowledge that just hasn't ever developed in the any community, much less in the CL community.

My own approach was to bite the bullet, learn Cocoa and then figure out how to make that work in CCL. That took a truly enormous amount of time and code development as demonstrated by the size of my contrib code to CCL for GUI development. Although I developed a lot of code to make Cocoa programming palatable within CCL, it’s still Cocoa programming. So it’s not platform independent and it’s not a trivial thing to learn. It is clearly geared towards people who are Cocoa literate or are willing to take the time to become so. That approach also requires an understanding of the different data structures used within Cocoa and CCL. A significant part of my contrib is devoted to making data conversions as trivial as possible and make Cocoa features like binding available to Lisp programmers, but you still need to know what to ask for and how things work in Cocoa. I also developed lisp controller classes that work compatibly with Cocoa widgets in much the same was as native Cocoa controller classes do for Objective-C programmers. But once again, you have to understand what these classes do within Apple’s paradigm in order to make use of them. As far as I can tell, there are very few people willing to climb that learning curve. So with each new release Apple makes additions and changes that make my code a little less useful.

Every once in a while I think about developing a small subset of useful gui classes that would make MCL-style programming possible again. I’m convinced that I could do that for Apple-based products, but have no clue how to do it for any other platform. And in the process I would effectively be creating yet another GUI API that would have to be documented and maintained as Apple’s internals evolved. I’m not sure that I’m smart enough to create an API that is both dirt-simple to learn and use and yet comprehensive enough to attract a large group of developers and would stand up to the test of time as things like VR or tactile/gesture input become more common.

Sorry, but I don’t think there is a simple solution to this problem. Perhaps it just requires someone younger than I am who doesn’t already know that such a thing is impossible to do. I wish them luck.