Wednesday, December 17, 2014

State of the MetaCommunity McCLIM fork - Apps "OK," fonts "Up in the air"

In my own small efforts in software programming, this year, I've made a fork of McCLIM -- a short overview provided in a previous 'blog entry, here at my DSP42 web log. It's been to nothing too sensational, as yet. I've made simply a few maintenance updates, and have added a dependency onto the mci-cltl-utils software system -- that much, as for applying a DEFCONSTANT* macro within McCLIM. 

Certainly, there are still some more maintenance updates to develop onto the fork, before getting along to any new developments onto McCLIM. In that regards, the last issue that I'd observed of it was that the font selector example is failing. It would appear to be due to something in regards to the interface onto the fonts table in CLX. Perhaps, that may easily resolved, insofar as the the present state of the source tree.  I think it serves to call some broader concerns to mind, however, insofar as developing an application architecture for Common Lisp desktop application development, within a contemporary computing environment.

Broadly, I've been using the Sharplispers CLX fork of Texas Instruments' original CLX codebase, and the CLX backend for McCLIM. I've tested a number of the applications provided in McCLIM, using the CLX backend. Specifically: The McCLIM listener, inspector, and debugger can be verified as running successfully, with that edition of CLX and on SBCL Furthermore, the Scigraph application has been updated to run by-in-large successfully, on that same platform, although again there are some maintenance issues with it.

I've also tested Climacs, on that platform. It runs successfully, too.

I'd tried applying the GTK Cairo backend for McCLIM, but without a lot of success in that port, presently. With some regrets, that may serve to make it more difficult to apply McCLIM onto mobile platforms. I had hoped that the GTK Cairo backend might've made a good component to apply for McCLIM on an Android platform, and well it still may. Presently, if it does not successfully run on so much as a contemporary Ubuntu Linux platform, then there's not much to show for it, at present.

One superficially minor change now developed in McCLIM: In regards to CLIM's multiple-value-setf behaviors, it should now be  portable onto ECL and CCL (ARM architecture), as well as SBCL (amd64) insofar as free/open source Common Lisp implementations. 

With regards to fonts: When adding a set of ASDF system definitions to the fork that I've made of the original Garnet source tree, I'd observed that Garnet is now extended with Truetype font support, such that utilizes CL-Vectors and extensionally, ZPB-TTF for providing a support for TrueType fonts onto CLX . The clx-truetype system may be applied not exclusively onto Garnet, though it is integrated with Garnet as in the gem-font-methods file in the same source tree.  One might hope that it would be fairly trivial, to apply clx-truetype likewise onto the CLX port in McCLIM. Insofar as with regards to fonts and typesetting in CLIM itself, there -- I think -- is one of the broader concerns of the matter. To a few superficially simple questions:

  • How may it be possible to provide functions for denoting superscript or subscript typesetting, in CLIM?
    • If not, then how may such functions be defined effectively onto McCLIM?
    • To what practical ends may such developments be focused?
  • May it be possible to implement the entire Cascading Stylesheets visual formatting model onto CLIM? Specifically, of CSS 2.2?
    • Note: `vertical-align` and related properties in the CSS model for inline blocks
  • Extensionally: How may it be possible to implement an entire MathML interface onto McCLIM?
Such questions might seem trivial, at the outset.

If the CSS 2.2 visual formatting model may be implemented onto McCLIM, perhaps it may be implemented as to extend of MetaObject Protocol. Hypothetically, any one or more metaclasses may be defined as to allow for a modular  implementation of the CSS 2.2 visual formatting model, such that the implementation may also be portable onto XSL Formatting Objects (spec version 1.1). Sure, it would be nothing too conceptually original, to develop an application protocol that may extend of both and that may be integrated with McCLIM, furthermore -- even insofar as for representation of text according to textual formatting specifiers. Historically, there's also DSSSL

XSL-FO and DSSSL may be particularly suited to a page-oriented media, if not specifically a page-oriented model for graphical user interface design. Insofar as page-oriented media in CLIM, of course there's also the McCLIM PostScript backend

Orthogonally, an implementation of SVG onto McCLIM may seem pragmatically "Out of the question," at this time. Though it would serve to keep pace with contemporary widget toolkits defined in C and C++ -- such as Qt, GTK, and Cairo, all of which provide support for rendering of graphics developed in a medium of SVG -- however, it may represent another distinctly non-trivial design issue to approach in any single fork onto McCLIM.

Of course, the design proposed of the Dobelle-App system -- as specifically with regards to development of mobile  applications in Common Lisp -- it would require that McCLIM or any other single graphical user interface toolkit would be suitably applicable in Common Lisp on a mobile platform, as well as on a desktop platform -- furthermore, beyond simple "Proof of concept" implementation. If a framework may be developed and applied for CLIM applications on desktop and mobile platforms -- not only for backing of a thesis article, but furthermore as a framework for commercial application development -- it would well need to be provably applicable in a commercial domain, in every feature of such a framework.

Still, such a matter may seem trivial, at the outset -- and well, there are so many novel things to take to attention, otherwise?