<?xml version="1.0"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>McCLIM – A powerful GUI toolkit for Common Lisp</title> <link>https://common-lisp.net/project/mcclim</link> <atom:link href="https://common-lisp.net/project/mcclim/rss.xml" rel="self" type="application/rss+xml" /> <language>en-us</language> <pubDate>Tue, 10 Jun 2025 18:39:09 +0000</pubDate> <item> <title>McCLIM 0.9.9 &quot;Ostara&quot; release</title> <link>https://common-lisp.net/project/mcclim/posts/McCLIM-099-Ostara-release.html</link> <pubDate>2025-03-11 15:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/McCLIM-099-Ostara-release.html</guid>  <description><![CDATA[ <h1>Table of Contents</h1>

<ol>
<li><a href="#orga7ffc08" >Changes</a>

<ol>
<li><a href="#org1220f1e" >More strict processing of geometry changes, repaints and recording</a></li>
<li><a href="#orgbd63dbb" >Dynamic slots for medium state and the current text line</a></li>
<li><a href="#org708b14c" >Thread-safe output history and drawing context</a></li>
<li><a href="#orgd873829" >Refactored text renderer for performance and alternative text directions</a></li>
<li><a href="#org867ad57" >New demos</a></li>
</ol></li>
<li><a href="#orga25f43e" >Future changes</a>

<ol>
<li><a href="#org72ac577" >The repaint queue</a></li>
<li><a href="#orgde756a2" >Input editing streams rewrite</a></li>
<li><a href="#orgcbcfaf6" >SDL2 backend and keyboard layouts</a></li>
</ol></li>
<li><a href="#org3574be9" >Closing remarks</a></li>
</ol>

<p>Dear All,</p>

<p>After a year of development it is time to make a release. The codename of this
version is &quot;Ostara&quot;, after the second of the eight annual pagan holidays
celebrating the arrival of spring. Ostara was a Germanic goddess representing
rebirth and is the equivalent of Easter.</p>

<p>In this release we mainly focus on robustness with numerous bugs fixed and a few
features implemented. Most notably McCLIM streams are now thread-safe to write
to and to draw on. Here is the list of committers and their number of commits
since the last release:</p>

<p>Daniel Kochmański (502), Charlie McMackin (15), Andrea Demichele (2), John
Carroll (1), José M. Á. Ronquillo Rivera (1) and Robert Brown (1).</p>

<p>This is not an exhaustive list of contributors, as it does not list people who
reported issues, updated the wiki, or performed other non-coding tasks. Thank
you!  Moreover I'd like to thank people who donate money to my <a href="https://www.patreon.com/c/jackdaniel_kochmanski" >Patreon</a> page,
your continuous support means a lot to me.</p>

<p><a id="orga7ffc08"></a></p>

<h1>Changes</h1>

<p>For a detailed list of changes, consult the NEWS file or the git log directly.
Below is a high-level overview of these changes.</p>

<p><a id="org1220f1e"></a></p>

<h2>More strict processing of geometry changes, repaints and recording</h2>

<p>This is the least visible change because it pertains to how we process updates
to states of CLIM stream panes. Previously when the program added new output,
the pane was resized immediately, followed by scrolling and repainting. That was
clearly suboptimal, especially when there is a lot of changes done in a short
period of time. Instead, we now batch these changes and execute them when
<code>STREAM-FINISH-OUTPUT</code> is called. That greatly improves performance and saves
visual glitches for certain scenarios.</p>

<p><a id="orgbd63dbb"></a></p>

<h2>Dynamic slots for medium state and the current text line</h2>

<p>To enable concurrent drawing threads, we needed to ensure that there are no
races regarding drawing options (like the drawing ink or the text style). To do
that, CLIM stream panes have a slot that contains an instance of a class that
has dynamic slots (for how this work see my <a href="https://turtleware.eu/posts/Dynamic-Vars---Return-of-the-Jedi.html" >blog post</a>). This allows for drawing
and writing text to streams concurrently from multiple threads. For example:</p>

<p><video controls>
  <source src='https://common-lisp.net/project/mcclim/static/media/099ostara/thread-safe-drawing.mp4'>
</video></p>

<p>In this demo we have seven concurrent threads:</p>

<ul>
<li>two threads print 1000 lines with prefixes &quot;XXX&quot; and &quot;YYY&quot;</li>
<li>four threads drawing dots in different colors</li>
<li>one thread monitors the current progress of printing lines</li>
</ul>

<p>Note that we may also scroll the output while these threads are still running
and modifying the sheet. The cursor is not corrupted and the output proceeds
without glitches.</p>

<p><a id="org708b14c"></a></p>

<h2>Thread-safe output history and drawing context</h2>

<p>Modifications to the output record history and writing pixels on a buffer are
mutually exclusive operations protected with locks. For forward compatibility,
all repaint requests by the program should be issued with <code>DISPATCH-REPAINT</code>.
Moreover the user program should not directly use operators that change the
output recording state of the stream.</p>

<p><video controls>
  <source src='https://common-lisp.net/project/mcclim/static/media/099ostara/concurrent-drawing.mp4'>
</video></p>

<p>Notice how multiple threads are modifying the sheet geometry and the cursor
position. The output record history is a bottleneck because each thread, after
drawing, needs to take the lock and update the record. This is suboptimal, but
enables us to quickly write throwaway code like this:</p>

<pre><code>(in-package &quot;CLIM-USER&quot;)

(defparameter *stream* (open-window-stream :width 800 :height 600))
(defparameter *stop* t)

(defun woosh (id ink)
  (setf *stop* nil)
  (with-drawing-options (*stream* :ink ink)
    (loop while (null *stop*) do
      (updating-output (*stream* :unique-id id :fixed-position t)
        (format *stream* &quot;Time: ~a~%&quot; (get-internal-real-time)))
      (sleep 1/30))))

(bt:make-thread (lambda () (woosh :thread-1 +dark-red+)))
(bt:make-thread (lambda () (woosh :thread-2 +dark-blue+)))
</code></pre>

<p>and in my opinion it is great for prototyping, because you can add additional
elements while the program is running without invoking arcane protocols.</p>

<p><a id="orgd873829"></a></p>

<h2>Refactored text renderer for performance and alternative text directions</h2>

<p>The text renderer has been refactored to achieve better performance and exploit
optimization opportunities when they are presented. For example a different code
path is executed when the text is not translucent.</p>

<p>That said, the most notable change with the text renderer is the ability to
change the line and the page directions:</p>

<p><video controls>
  <source src='https://common-lisp.net/project/mcclim/static/media/099ostara/draw-text-test.mp4'>
</video></p>

<p>These changes apply to DRAW-TEXT. Line-oriented integration with CLIM streams
that allows mixing the text that has different directions is not yet
implemented, but we can already mix text and graphics, and the latter will be
correctly wrapped along the text when necessary.</p>

<p><img src="https://common-lisp.net/project/mcclim/static/media/099ostara/mix-text-graphics.png" alt="Mixing in graphics in a text line" /></p>

<p><a id="org867ad57"></a></p>

<h2>New demos</h2>

<p>I wrote new demos that may be started from the system <code>clim-examples</code>:</p>

<ul>
<li><strong>incremental redisplay:</strong> demonstrates how to work with output record caches</li>
<li><strong>animation with pulse:</strong> an animation with a timer synchronizing redisplay</li>
<li><strong>concurrent drawing:</strong> a demo where we can spin any number of drawing threads</li>
<li><strong>concurrent writing:</strong> a stress test for concurrent writing lines to a stream</li>
<li><strong>concurrent griding:</strong> a stress test with concurrent drawing with many records</li>
</ul>

<p><a id="orga25f43e"></a></p>

<h1>Future changes</h1>

<p><a id="org72ac577"></a></p>

<h2>The repaint queue</h2>

<p>The thread-safety of CLIM streams is factored out from a branch <code>repaint-queue</code>.
This branch works, but it still has various regressions that need to be
addressed before merging. The results are very promising and its effect
compounds with thread-safety, because drawing locks the output history far less
often, while recording is rather cheap.</p>

<p><a id="orgde756a2"></a></p>

<h2>Input editing streams rewrite</h2>

<p>This work is mostly done but it needs more testing and there are a few bugs that
need to be addressed before merging. This change involves also better command
completions that include a fuzzy completer, and makes text editing much easier.
If you want to see the current state of it check out <code>input-editing</code> branch.</p>

<p><a id="orgcbcfaf6"></a></p>

<h2>SDL2 backend and keyboard layouts</h2>

<p>I didn't work on either of these tasks since the last release, but I plan to
finish them after merging branches <code>repaint-queue</code> and <code>input-editing</code>. After
finishing SDL2 branch and keyboard layouts I want to make the next release.</p>

<p><a id="org3574be9"></a></p>

<h1>Closing remarks</h1>

<p>McCLIM improves on a daily basis, and this trend continues. I'm very happy that
I've been able to make a timely release unlike the last one. Fixing numerous
issues further accelerates other improvements. From my subjective perspective
the software is much more resilient than a year ago.</p>

<p>You may grab the latest release from here:
<a href="https://codeberg.org/McCLIM/McCLIM/releases/tag/0.9.9-ostara">https://codeberg.org/McCLIM/McCLIM/releases/tag/0.9.9-ostara</a>.</p>

<p>Best regards,<br/>
Daniel Kochmański</p>
 ]]></description> </item><item> <title>McCLIM 0.9.8 &quot;Yule&quot; release</title> <link>https://common-lisp.net/project/mcclim/posts/McCLIM-098-Yule-release.html</link> <pubDate>2023-12-27 13:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/McCLIM-098-Yule-release.html</guid>  <description><![CDATA[ <p>Dear All,</p>

<p>After over 5 years of development we've decided to make a release. The last
release version &quot;0.9.7 Imbolc&quot; dates to 2018. Yule is a Germanic Midwinter
festival that was later incorporated into Christmas.</p>

<p>This release is long overdue. The reason for that is because we've wanted to
have too many things finished in it - I'll elaborate on these later. This
release would not happen without contributions from many people who wrote code,
reported bugs and provided guidance to beginners.</p>

<h2>Changes</h2>

<p>Here is the list of commiters and the number of commits since the last release:</p>

<p>Daniel Kochmański (1667), Jan Moringen (582), Elias Mårtenson (182), Nisar Ahmad
(90), Andrea Demichele (89), Cyrus Harmon (62), José Ronquillo Rivera (18),
Christoph Keßler (18), Eric Timmons (16), death (12), Robert Strandh (11), Phil
Mueller (7), Henry Harrington (5), hes (5), chuchana (4), Karsten Poeck (4),
Jingtao Xu (3), Pouar (3), bmansurov (3), contrapunctus-1 (3), Charles Zhang
(2), Fred Gilham (2), contrapunctus (2), duuqnd (2), goose121 (2), Howard Shrobe
(2), Alan Zimmerman (1), Dirk Eßer (1), Ingo Krabbe (1), Javier Olaechea (1),
Jeremiah LaRocco (1), John Lorentzson (2), Knut Olav Bøhmer (1), Kyle Nusbaum
(1), Mark Evenson (1), Nathan Shostek (1), Philipp Marek (1), Tarn W. Burton
(1), William S. Annis (1), crunsk (1), luyiranl2010 (1), modula t. worm (1),
ormf (1), rainthree (1), steiner (1), Неточка Незванова (1).</p>

<p>A few opinionated feature highlights that may be interesting to users:</p>

<ul>
<li>The new inspector Clouseau written by Jan Moringen</li>
<li>Inclusion of the Freetype renderer by Elias Mårtenson</li>
<li>New extension &quot;mcclim-dot&quot; by Eric Timmons (graphviz layout for graphs)</li>
<li>Rewrite of the X11 renderer and a new SVG backend by Daniel Kochmański</li>
<li>Many important UX improvements by Nisar Ahmad and Andrea Demichele</li>
</ul>

<p>Here is a more complete (yet still incomplete and more noisy) list of changes.
For more details please consult the repository history log.</p>

<ul>
<li>Listener UX improvements</li>
<li>Refactor command tables and commands parsing</li>
<li>Refactor of the sheet and the mirror implementation</li>
<li>Numerous new examples</li>
<li>Unification of CLX backends into a single system</li>
<li>bugfix: TTF font caches do not overlap between backends</li>
<li>Add an alternative (not default) TTF renderer based on FFI to FreeType</li>
<li>bugfix: address numerous issues in tab-layout</li>
<li>Improved support for text transformations</li>
<li>Bundle cl-dejavu fonts as a dependency</li>
<li>Portability fixes for CL implementations</li>
<li>Better separation of responsibilities between sheets and mediums</li>
<li>TABLE-FORMATTING improvements</li>
<li>Support for system clipboard and for internal selection</li>
<li>Remove invalid assumptions about the sheet coordinates while scrolling</li>
<li>Full rewrite of CLX renderer to use XRender (transparency, transformations, clipping)</li>
<li>Incremental redisplay partial rewrite and bug fixes</li>
<li>UX imrovements for gadget states with regard to pointer events</li>
<li>Bug fixes and conformity improvements for PS and PDF backends</li>
<li>Pull bezier curve and bezier area extensions as core regions</li>
<li>Improved set of colors for MAKE-CONTRASTING-INKS</li>
<li>Improved set of patterns for MAKE-CONTRASTING-DASH-PATTERNS</li>
<li>A new protocol for handling patterns, transformations and arbitrary designs</li>
<li>Rewrite mcclim-render extension</li>
<li>Enable rendering directly to the pattern or a raster file</li>
<li>Flesh out the protocol to implement indirect inks</li>
<li>Remove obsolete backend &quot;beagle&quot;</li>
<li>Rewrite of the demo DRAWING-TESTS</li>
<li>Improved support for arcs, angles and ellipses</li>
<li>Geometry module partial rewrite - conformance and performance improvements</li>
<li>Improved class hierarchy for input events</li>
<li>Space requirements rewrite to allow specification of padding and margins</li>
<li>Menu bar rewrite to handle keyboard accelerators and arrows</li>
<li>Remove runtime overhead from protocol classes</li>
<li>More conforming handling of line style unit</li>
<li>Introduce the concept of a page with four margins</li>
<li>Implement word wrap and extend FILLING-OUTPUT and INDENTING-OUTPUT macros</li>
<li>Rewrite PRESENTATION-SUBTYPEP and PRESENTATION-TYPEP for conformance</li>
<li>Much faster TTF renderer, implement kerning and tracking, thread safe rendering</li>
<li>Pixel-perfect FONT-TEXT-EXTENT implementation for the TTF renderer, transformations</li>
<li>Gadgets UX improvements for both space composition and event handling</li>
<li>Better PRINT-OBJECT methods for numerous internal objects</li>
<li>Rewrite EVENT-QUEUE for thread safety and performance, extend TIMEOUT interface</li>
<li>Fix McCLIM regression to work on non-SMP systems</li>
<li>Improved parsing for space requirements</li>
<li>Rewrite the implementation of mapping between text styles and fonts</li>
<li>Refactor of the EXTENDED-INPUT-STREAM</li>
<li>Add numerous missing ACCEPT-PRESENT-DEFAULT methods for dialog-views</li>
<li>Improved repaint-sheet handling (less repaints, more performant)</li>
<li>Improvements to numerous presentation methods in functions ACCEPT and PRESENT</li>
<li>Presentation translator lookup rewrite</li>
<li>Selection API can carry arbitrary presentations with &quot;paste&quot; translators</li>
<li>Extensions documentation in manual, various fixups and improvements</li>
<li>Specification clarifications in the bundled latex source code</li>
<li>Implement double buffering in the CLX backend</li>
<li>New protocols to set the frame (and sheet) pretty name and icon</li>
<li>Refactor mirrored/non-mirrored event distribution and add synthetic events</li>
<li>Rewrite pointer tracking, pointer grabbing and drag&amp;drop support</li>
<li>Include the new inspector &quot;Clouseau&quot; with bundled applications, remove old the inspector</li>
<li>Put Franz-specific extensions to the system &quot;mcclim-franz&quot;</li>
<li>A new command parameter OUTPUT-DESTINATION to redirect the command output</li>
<li>Improve frame and panes definitions to allow dynamic reinitialization</li>
<li>Improve PROCESS-NEXT-EVENT specification and implementations for clarity and completness</li>
<li>It is possible to define a presentation to command translator with the argument</li>
<li>Rework accepting values to remove a few kludges</li>
<li>Refactor FORMAT-GRAPH-FROM-ROOT and the layout algorithm for correctness</li>
<li>Numerous cleanups to avoid accessing internal symbols and have a clean file structure</li>
<li>Introduce the presentation BLANK-AREA (similar to NULL-PRESENTATION) that allows parameters</li>
<li>Provide an uniform interface for mapping over command table menu items and keystrokes</li>
<li>Improve the protocol for defining new ports (backends)</li>
<li>Allow for existence of ungrafted mediums</li>
<li>Allow runtime replacement of the menu bar in the frame</li>
<li>Better separation of responsibilities between frames and frame managers</li>
<li>Improved gesture and event matching that allows wildcards</li>
<li>Minor integrations between CLIM-DEBUGGER and Clouseau</li>
<li>Removal of numerous internal obsolete interfaces</li>
<li>Thread-safe implementation of the function EXECUTE-FRAME-COMMAND</li>
<li>Better support for repeated grafting and degrafting sheets (migrating frames between backends)</li>
<li>Implement a new backend that creates SVG documents</li>
<li>Introduce a new macro for drawing backends CLIME:WITH-OUTPUT-TO-DRAWING-STREAM</li>
<li>Include a new extension &quot;mcclim-tooltips&quot;</li>
<li>Include a new extension &quot;mcclim-dot&quot;</li>
<li>Write new implementation of text-field and text-editor gadgets (with pointer selection etc)</li>
<li>Allow for preloaded fonts in the application image</li>
<li>Flesh out important protocols useful for writing new backends</li>
<li>Add a new gesture types :TIMER, :INDIRECT, :POINTER-MOTION and :POINTER-SCROLL</li>
<li>TTF renderer consults the graft DPI to decide on the font scaling</li>
</ul>

<h2>Work-in-progress features</h2>

<p>I've mentioned some features that I've wanted to include in this release - that
delayed it by over two years. I'll elaborate on them now, because they are all
in a quite advanced &quot;work in progress&quot; state:</p>

<h3>SDL2 backend</h3>

<p>The SDL2 backend is an alternative backend that is meant to work on platforms
that do not feature X11. It is mostly complete, but since SDL2 text input has a
bad protocol, we need to rely only on keyboard events. To handle text correctly
we need to transform them to text.</p>

<p>The current version of the backend features the software renderer. Hardware
acceleration will come after that. In parallel I'm also writing a manual for
developers that explains how to write new backends.</p>

<h3>Keyboard layouts</h3>

<p>CLX does not implement the XKB protocol. That means that McCLIM applications
don't benefit from keyboard layouts. To address that I'm writing a library that
parses xkb definitions and implements layouts like the project xkbcommon does.
Such library will also enable the SDL2 backend (see above).</p>

<h3>Input editing streams rewrite</h3>

<p>McCLIM implements interactive stream handling with help of Drei. I've already
written the new input editor that is better integrated with the system and it is
used to implement gadgets. Integrating this editor with streams will enable
improvements to the command line processor and accepting values streams.</p>

<h3>Separate repaint queue</h3>

<p>I've already made a few prototypes that implement animations using a separate
repaint queue. They show a nice performance of 400 FPS. The biggest win will be
that the input processing and the sheet repaint will not block each other.</p>

<h2>Closing remarks</h2>

<p>McCLIM improves on daily basis and we hope that this trend will continue. I'm
sorry for dragging the release - I'll try to make releases more often so that
changes may be fleshed out in more details and on more timely basis. I'd like to
thank all contributors and people who supported us along the way.</p>

<p>I'd like to wish you all a Happy New Year :-)</p>

<p><a href="https://codeberg.org/McCLIM/McCLIM/releases/tag/0.9.8-yule" >download</a></p>

<p>Best regards,<br/>
Daniel Kochmański</p>
 ]]></description> </item><item> <title>Migration to Codeberg</title> <link>https://common-lisp.net/project/mcclim/posts/Migration-to-Codeberg.html</link> <pubDate>2023-03-13 20:30</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Migration-to-Codeberg.html</guid> <category><![CDATA[ clim ]]></category><category><![CDATA[ lisp ]]></category> <description><![CDATA[ <p>Dear Community,</p>

<p>Our repository is migrated to a new hosting platform Codeberg:
<a href="https://codeberg.org/McCLIM/McCLIM" >https://codeberg.org/McCLIM/McCLIM</a>.
The old repository is archived in read-only state - that means that old
links and references will work.</p>

<p>I've wanted to migrate McCLIM for quite some time and planned that for after a
release, but it is frequently postponed by one-more-thing to tweak, so I've
decided to take the action now.</p>

<p>As for the reason - we've discussed it a few times on IRC. It boils down to
the fact that Github/Microsoft uses our code without attribution and without
respecting its license, in order to improve its product &quot;copilot&quot;.</p>

<p>Thank you for your understanding, sorry for the inconvenience(!), and see you
in the new place. :-)</p>

<p>Sincerely yours,<br/>
Daniel Kochmański</p>
 ]]></description> </item><item> <title>Progress report #12</title> <link>https://common-lisp.net/project/mcclim/posts/Progress-report-12.html</link> <pubDate>2021-07-13 19:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Progress-report-12.html</guid> <category><![CDATA[ clim ]]></category><category><![CDATA[ lisp ]]></category> <description><![CDATA[ <p>Dear Community,</p>

<p>A lot of time passed since the last blog entry. I'm sorry for neglecting this.
In this post, I'll try to summarize the past two and a half year.</p>

<h2>Finances and bounties</h2>

<p>Some of you might have noticed that the bounty program has been suspended. The
BountySource platform lost our trust around a year ago when they have changed
their ToS to include:</p>

<blockquote>
<p>If no Solution is accepted within two years after a Bounty is posted, then the
Bounty will be withdrawn, and the amount posted for the Bounty will be
retained by Bountysource.</p>
</blockquote>

<p>They've quickly retracted from that change, but the trust was already lost. Soon
after, I've suspended the account and all donations with this platform were
suspended. BountySource refunded all our pending bounties.</p>

<p>All paid bounties were summarized in previous posts. Between 2016-08-16 and
2020-06-16 (46 months of donations) we have collected in total $18700. The
Bounty Source comission was 10% collected upon withdrawal - all amounts
mentioned below are presented for <strong>before</strong> the comission was claimed.</p>

<p>During that time $3200 was paid to bounty hunters who solved various issues in
McCLIM. The bounty program was a limited success - solutions that were
contributed were important, however harder problems with bounties were not
solved. That said, a few developers who contribute today to McCLIM joined in the
meantime and that might be partially thanks to the bounty program.</p>

<p>When the fundraiser was announced, I've declared I would withdraw $600 monthly
from the project account. In the meantime I've had a profitable contract and for
two years I stopped withdrawing money. During the remaining three years I've
withdrawn $15500 ($440/month) from the account.</p>

<p>As of now we don't have funds and there is no official way to donate money to
the project (however, this may change in the near future). I hope that this
summary is sufficient regarding the fundraiser. If you have further questions,
please don't hesitate to contact me, and I'll do my best to answer them.</p>

<p>I'd like to thank all people who donated to the project. Your financial support
made it possible for me to work on the project more than I would be able without
it. The fact that people care about McCLIM enough to contribute to it money
gives me the motivation and faith that working on the codebase is an important
effort that benefits the Common Lisp community.</p>

<h2>Improvements</h2>

<p>The last update was in 2018-12-31. A lot of changes accumulated in the meantime.</p>

<ul>
<li>Bordered output bug fixes and improvements -- Daniel Kochmański</li>
<li>Gadget UX improvements (many of them) -- Jan Moringen</li>
<li>Text styles fixes and refactor -- Daniel Kochmański</li>
<li>Freetype text renderer improvements -- Elias Mårtenson</li>
<li>Extended input stream abstraction rewrite -- Daniel Kochmański</li>
<li>Implementation of presentation methods for dialog-views -- admich</li>
<li>Encapsulating stream missing methods implementation -- admich</li>
<li>indenting-output-stream fixes -- Jan Moringen</li>
<li>drawing-tests demo rewrite -- José Ronquillo Rivera</li>
<li>Line wrap on the word boundaries -- Daniel Kochmański</li>
<li>New margin implementation (extended text formatting) -- Daniel Kochmański</li>
<li>Presentation types and presentation translators refactor -- Daniel Kochmański</li>
<li>Input completion and accept methods bug fixes and reports -- Howard Shrobe</li>
<li>Clipboard implementation (and the selection translators) -- Daniel Kochmański</li>
<li>CLIM-Fig demo improvements and bug fixes -- Christoph Keßler</li>
<li>The pointer implementation (fix the specification conformance) -- admich</li>
<li>Drei kill ring improvements -- Christoph Keßler</li>
<li>McCLIM manual improvements -- Jan Moringen</li>
<li>Frame icon and pretty name change extensions -- Jan Moringen</li>
<li>Cleanups and extensive testing -- Nisar Ahmad</li>
<li>pointer-tracking rewrite -- Daniel Kochmański</li>
<li>drag-and-drop translators rewrite -- Daniel Kochmański</li>
<li>Complete rewrite of the inspector Clouseau -- Jan Moringen</li>
<li>Rewrite of the function distribute-event -- Daniel Kochmański and Jan Moringen</li>
<li>Adding new tests and organizing them in modules -- Jan Moringen</li>
<li>Various fixes to the delayed repaint mechanism -- Jan Moringen</li>
<li>CLX backend performance and stability fixes -- Christoph Keßler</li>
<li>PS/PDF/Raster backends cleanups and improvements -- Jan Moringen</li>
<li>Drei regression fixes and stability improvements -- Nisar Ahmad</li>
<li>Geometry module refactor and improvements -- Daniel Kochmański</li>
<li>Separating McCLIM code into multiple modules -- Daniel Kochmański and Jan Moringen</li>
<li>Frames and frame managers improvements -- Jan Moringen and Daniel Kochmański</li>
<li>Frame reinitialization -- Jan Moringen</li>
<li>PDF/PS backends functionality improvements -- admich</li>
<li>Menu code cleanup -- Jan Moringen</li>
<li>Pane geometry and graph formatting fixes -- Nisar Ahmad</li>
<li>Numerous CLX cleanups and bug fixes -- Daniel Kochmański and Jan Moringen</li>
<li>Render backend stability, performance and functionality fixes -- Jan Moringen</li>
<li>Presentation types more strict interpretation -- Daniel Kochmański</li>
<li>External Continuous Integration support -- Jan Moringen</li>
<li>Continuous Integration support -- Nisar Ahmad</li>
<li>Improved macros for recording and table formatting -- Jan Moringen</li>
<li>Better option parsing for define-application-frame -- Jan Moringen</li>
<li>Separation between the event queue and the stream input buffer -- Daniel Kochmański</li>
<li>Examples cleanup -- Jan Moringen</li>
<li>Graph formatting cleanup -- Daniel Kochmański</li>
<li>Stream panes defined in define-application-frames refactor -- admich</li>
<li>Menu bar rewrite (keyboard navigation, click to activate) -- Daniel Kochmański</li>
<li>Thread-safe execute-frame-command function -- Daniel Kochmański</li>
<li>Mirroring code simplification for clx-derived backends -- Daniel Kochmański</li>
<li>Arbitrary native transformations for sheets (i.e. zooming) -- Daniel Kochmański</li>
<li>extended-streams event matching improvements -- Jan Moringen</li>
<li>Render backend performance improvements -- death</li>
<li>drei fixes for various issues -- death</li>
<li>drei various cleanups -- Jan Moringen</li>
<li>clim-debugger improvements -- Jan Moringen</li>
<li>Manual spelling fixes and proofreading -- contrapunctus</li>
</ul>

<p>This is not an exhaustive list of changes. For more details, please consult the
repository history. Many changes I've introduced during this iteration were a
subject of a careful (and time-consuming) peer review from Jan Moringen which
resulted in a better code quality. Continuous integration provided by Nisar
Ahmad definitely made my life simpler. I'd like to thank all contributors for
their time and energy spent on improving McCLIM.</p>

<h2>Pending work</h2>

<p>If you are working on some exciting improvement for McCLIM which is not ready,
you may make a &quot;draft&quot; pull request in the McCLIM repository. Currently, there
are three such branches:</p>

<ul>
<li><p>the SLIME-based <a href="https://github.com/McCLIM/McCLIM/pull/1193" >backend</a> for CLIM
by Luke Gorrie</p></li>
<li><p>the dot-based graph layout
<a href="https://github.com/McCLIM/McCLIM/pull/1197" >extension</a> by Eric Timmons</p></li>
<li><p>the xrender <a href="https://github.com/McCLIM/McCLIM/pull/1196" >backend</a> by Daniel
Kochmański</p></li>
</ul>

<p>Other than that, I've recently implemented the polygon triangulation algorithm
that is meant to be used in the xrender backend (but could be reused i.e. for
opengl). Currently, I'm refining the new rendering for clx (xrender). After that,
I want to introduce a portable double buffering and a new repaint queue. Having
these things in place after extensive testing, I want to roll out a new release
of McCLIM.</p>

<p>Sincerely yours,<br/>
Daniel Kochmański</p>
 ]]></description> </item><item> <title>&quot;Yule&quot; progress report</title> <link>https://common-lisp.net/project/mcclim/posts/Yule-progress-report.html</link> <pubDate>2018-12-31 23:59</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Yule-progress-report.html</guid>  <description><![CDATA[ <p>Dear Community,</p>

<p>Winter solstice is a special time of year when we gather together with people
dear to us. In pagan tradition this event is called &quot;Yule&quot;. I thought it is a
good time to write a progress report and a summary of changes made since the
last release. I apologise for infrequent updates. On the other hand we are busy
with improving McCLIM and many important (and exciting!) improvements have been
made in the meantime. I'd love to declare it a new release with a code name
&quot;Yule&quot; but we still have some regressions to fix and pending improvements to
apply. We hope though that the release 0.9.8 will happen soon.</p>

<p>We are very excited that we have managed to resurrect interest in McCLIM among
Common Lisp developers and it is thanks to the help of you all - every
contributor to the project. Some of you provide important improvement
suggestions, issue reports and regression tests on our
<a href="https://github.com/McCLIM/McCLIM/issues" >tracker</a>. Others develop applications
with McCLIM and that helps us to identify parts which need improving. By
creating pull requests you go out of your comfort zone to help improve the
project and by doing a peer review you prevent serious regressions and make code
better than it would be without that. Perpetual testing and frequent discussions
on <a href="" >#clim @ irc.libera.chat</a> help to keep the project in shape. Financial
<a href="https://salt.bountysource.com/teams/mcclim/supporters" >supporters</a> allow us to
create bounties and attract by that new contributors.</p>

<h2>Finances and bounties</h2>

<p>Speaking of finances:
our <a href="https://salt.bountysource.com/teams/mcclim" >fundraiser</a> receives a steady
stream of funds of approximately $300/month. We are grateful for that. Right now
all money is destined for bounties. A few times bounty was not claimed by bounty
hunters who solved the issue – in that case I've collected them and re-added to
funds after talking with said people. Currently our funds available for future
activities are $3,785 and active bounties on issues waiting to be solved are
$2,850 (split between 7 issues). We've already paid $2,450 total for solved
issues.</p>

<p>Active bounties:</p>

<ul>
<li>[$600] drawing-tests: improve and refactor (new!).</li>
<li>[$600] streams: make SEOS access thread-safe (new!).</li>
<li>[$500] Windows Backend.</li>
<li>[$450] clx: input: english layout.</li>
<li>[$300] listener: repl blocks when long process runs.</li>
<li>[$150] UPDATING-OUTPUT not usable with custom gadgets.</li>
<li>[$150] When flowing text in a FORMATTING-TABLE, the pane size is used instead of the column size.</li>
</ul>

<p>Claimed bounties (since last time):</p>

<ul>
<li>[$100] No applicable method for REGION-CONTAINS-POSITION-P -- fixed by Cyrus Harmon and re-added to the pool.</li>
<li>[$200] Text rotation is not supported -- fixed by Daniel Kochmański.</li>
<li>[$400] Fix Beagle backend -- cancelled and re-added to the pool.</li>
<li>[$100] with-room-for-graphics does not obey height for graphics not starting at 0,0 -- fixed by Nisar Ahmad.</li>
<li>[$100] Enter doesn't cause input acceptance in the Listener if you hit Alt first -- fixed by Charles Zhang.</li>
<li>[$100] Listener commands with &quot;list&quot; arguments, such as Run, cannot be executed from command history -- fixed by Nisar Ahmad.</li>
<li>[$200] add PDF file generation (PDF backend) -- fixed by Cyrus Harmon;
  This bounty will be re-added to the pool when the other backer Ingo Marks accepts the solution.</li>
</ul>

<h2>Improvements</h2>

<p>I'm sure you've been waiting for this part the most. Current mid-release
improvements and regressions are vast. I'll list only changes which I find the
most highlight-able but there are more and most of them are very useful! The
whole list of commits and contributors may be found in
the <a href="https://github.com/McCLIM/McCLIM/commits/master" >git log</a>. There were also
many changes not listed here related to the CLX library.</p>

<ul>
<li>Listener UX improvements by Nisar Ahmad.</li>
<li>Mirrored sheet implementation refactor by Daniel Kochmański.</li>
<li>New demo applications and improvements to existing ones,</li>
<li>Font rendering refactor and new features:</li>
</ul>

<p>This part is a joint effort of many people. In effect we have now two quite
  performant and good looking font rendered. Elias Mårtenson resurrected FFI
  Freetype alternative text renderer which uses Harfbuzz and fontconfig found in
  the foreign world. Daniel Kochmański inspired by Freetype features implemented
  kerning, tracking, multi-line rendering and arbitrary text transformations for
  the native TTF renderer. That resulted in a major refactor of font rendering
  abstraction. Missing features in the TTF renderer are font shaping and
  bidirectional text.</p>

<ul>
<li>Experiments with xrender scrolling and transformations by Elias Mårtenson,</li>
<li>Image and pattern rendering refactor and improvements by Daniel Kochmański.</li>
</ul>

<p>Both experiments with xrender and pattern rendering were direct inspiration for
  work-in-progress migration to use xrender as default rendering mechanism.</p>

<p>Patterns have now much better support coverage than they used to have. We may
  treat pattern as any other design. Moreover it is possible to transform patterns
  in arbitrary ways (and use other patterns as inks inside parent ones). This has
  been done at expense of
  a <a href="https://github.com/McCLIM/McCLIM/issues/637" >performance regression</a> which we
  plan to address before the release.</p>

<ul>
<li>CLX-fb refactor by Daniel Kochmański:</li>
</ul>

<p>Most of the work was related to simplifying macrology and class hierarchy. This
  caused small performance regression in this backend (however it may be fixed
  with the current abstraction present there).</p>

<ul>
<li>Performance and clean code fixes by Jan Moringen:</li>
</ul>

<p>Jan wrote a very useful tool
  called <a href="https://github.com/scymtym/clim.flamegraph/tree/future" >clim-flamegraph</a>
  (it works right now only on SBCL). It helped us to recognize many performance
  bottlenecks which would be hard to spot otherwise. His contributions to the code
  base were small (LOC-wise) and hard to pin-point to a specific feature but very
  important from the maintanance, correctness and performance point of view.</p>

<ul>
<li>Text-size example for responsiveness and UX by Jan Moringen,</li>
<li>Various gadget improvements by Jan Moringen,</li>
<li>Box adjuster gadget rewrite by Jan Moringen:</li>
</ul>

<p>clim-extensions:box-adjuster-gadget deserves a separate mention due to its
  usefulness and relatively small mind share. It allows resizing adjacent panes
  by dragging a boundary between them.</p>

<ul>
<li>New example for output recording with custom record types by Robert Strandh,</li>
<li>PostScript and PDF renderer improvements by Cyrus Harmon,</li>
<li>Scrigraph and other examples improvements by Cyrus Harmon,</li>
<li>Multiple regression tests added to drawing-tests by Cyrus Harmon,</li>
<li>Ellipse drawing testing and fixes by Cyrus Harmon,</li>
<li>Better contrasting inks support by Jan Moringen,</li>
<li>Output recording and graphics-state cleanup by Daniel Kochmański,</li>
<li>WITH-OUTPUT-TO-RASTER-IMAGE-FILE macro fixed by Jan Moringen,</li>
<li>Regions may be printed readably (with #. hack) by Cyrus Harmon,</li>
<li>event-queue processing rewrite by Nisar Ahmad and  Daniel Kochmański:</li>
</ul>

<p>This solves a long standing regression – McCLIM didn't run correctly on
  implementations without support for threading. This rewrite cleaned up a few
  input processing abstractions and provided thread-safe code. SCHEDULE-EVENT
  (which was bitrotten) works as expected now.</p>

<ul>
<li>Extensive testing and peer reviews by Nisar Ahmad:</li>
</ul>

<p>This role is easy to omit when one looks at commits but it is hard to
  overemphasize it – that's how important testing is. Code would be much worse if
  Nisar didn't put as much effort on it as he did.</p>

<h2>Plans</h2>

<p>Before the next release we want to refactor input processing in McCLIM and make
all stream operations thread-safe. Refactoring input processing loop will allow
better support for native McCLIM gadgets and streams (right now they do not work
well together) and make the model much more intuitive for new developers. We
hope to get rid of various kludges thanks to that as well. Thread-safe stream
operations on the other hand are important if we want to access CLIM application
from REPL in other process than the application frame (right now drawing from
another process may for instance cause output recording corruption). This is
important for interactive development from Emacs. When both tasks are finished
we are going to release the 0.9.8 version.</p>

<p>After that our efforts will focus on improving X11 backend support. Most notably
we want to increase use of the xrender extension of clx and address a long standing
issue with <a href="https://github.com/McCLIM/McCLIM/issues/35" >non-english layouts</a>.
When both tasks are accomplished (some other features may land in but these two
will be my main focus) we will release 0.9.9 version.</p>

<p>That will mark a special time in McCLIM development. Next release will be 1.0.0
what is a significant number. The idea is to devote this time explicitly for
testing, cleanup and documentation with a feature freeze (i.e no new
functionality will be added). What comes after that nobody knows. Animations?
New backends? Interactive documentation? If you have some specific vision in
which direction McCLIM should move all you have to do is to take action and
implement the necessary changes :-).</p>

<h2>Merry Yule and Happy New Year 2019</h2>

<p>This year was very fruitful for McCLIM development. We'd like to thank all
contributors once more and we wish you all (and ourselves) that the next year
will be at least as good as this one, a lot of joy, creativeness and Happy
Hacking!</p>

<p>Sincerely yours,<br/>
McCLIM Development Team</p>
 ]]></description> </item><item> <title>Sheets as ideal forms</title> <link>https://common-lisp.net/project/mcclim/posts/Sheets-as-ideal-forms.html</link> <pubDate>2018-03-05 17:30</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Sheets-as-ideal-forms.html</guid> <category><![CDATA[ port ]]></category><category><![CDATA[ sheet ]]></category><category><![CDATA[ graft ]]></category><category><![CDATA[ medium ]]></category><category><![CDATA[ drawing ]]></category><category><![CDATA[ graphics ]]></category><category><![CDATA[ clim ]]></category><category><![CDATA[ lisp ]]></category> <description><![CDATA[ <p>CLIM operates on various kinds of objects. Some are connected by an inheritance,
other by a composition and some are similar in a different sense.</p>

<p>As programmers, we often deal with the inheritance and the composition,
especially since OOP is a dominating paradigm of programming (no matter if the
central concept is the object or the function). Not so often we deal with the
third type of connection, that is the Form and the phenomena which are merely a
shadow mimicking it<code>[1]</code>.</p>

<p>Let us talk about sheets. The sheet is a region<code>[2]</code> with an infinite resolution
and potentially infinite extent on which we can draw. Sheets may be arranged
into hierarchies creating a windowing system with a child-parent relation. Sheet
is the Form with no visual appearance. What we observe is an approximation of
the sheet which may be hard to recognize when compared to other approximations.</p>

<p><code>[1]:</code> <a href="https://en.wikipedia.org/wiki/Theory_of_forms" >Theory of forms</a>.</p>

<p><code>[2]:</code> And many other things.</p>

<h2>Physical devices</h2>

<p>Sheet hierarchies may be manipulated without a physical medium but to make them
visible we need to draw them. CLIM defines <code>ports</code> and <code>grafts</code> to allow rooting
sheets to a display server. <code>medium</code> is defined to draw sheet approximation on
the screen<code>[3]</code>.</p>

<p>How should look a square with side length 10 when drawn on a sheet? Since it
doesn't have a unit we can't tell. Before we decide on a unit we choose we need
to take into consideration at least the following scenarios:</p>

<ol>
<li><p>If we assume device-specific unit results may drastically differ (density may
vary from say 1200dpi on a printer down to 160dpi on a desktop<code>[4]</code>!. The very
same square could have 1cm on a paper sheet, 7cm and 10cm on different displays
and 200cm on a terminal.  From the perspective of a person who uses the
application, this may be confusing because physical objects don't change size
without a reason.</p></li>
<li><p>Another possible approach is to assume the physical world distances measured
in millimeters (or inches if you must). Thanks to that object will have a
similar size on different mediums. This is better but still not good. We have to
acknowledge that most computer displays are pixel based. Specifying distances in
millimeters will inevitably lead to worse drawing quality<code>[5]</code> (compared to the
situation when we use pixels as the base unit). Moreover, conversion from
millimeter values to the pixel will most inevitably lead to work on floats.</p></li>
<li><p>Some applications may have specific demands. For instance, application is
meant to run on a bus stop showing arrival times. Space of the display is very
limited and we can't afford approximation from the high-density specification
(in pixels or millimeters) to 80x40 screen (5 lines of 8 characters with 5x8
dots each). We need to be very precise and the ability to request a particular
unit size for a sheet is essential. Of course, we want to test such application
on a computer screen.</p></li>
</ol>

<p>I will try to answer this question in a moment. First, we have to talk about the
<code>CLIM</code> specification and limitations imposed by McCLIM's implementation of
grafts.</p>

<p><code>[3]</code>: See some <a href="http://bauhh.dyndns.org:8000/clim-spec/12-4.html" >general recommendations</a>.</p>

<p><code>[4]</code>: Technically it should be <a href="https://99designs.com/blog/tips/ppi-vs-dpi-whats-the-difference/" >PPI, not DPI</a> (pixels per inch).</p>

<p><code>[5]</code>: Given programmer specifies sheet size in integers (like 100x100).</p>

<h2>Ports, grafts, and McCLIM limitations</h2>

<p>If a port is a physical connection to a display server then graft is its screen
representation. The following picture illustrates how the same physical screen
may be perceived depending on its settings and the way we look at it.</p>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/graft-drawing.png" alt="Graft drawing" /></p>

<p>As we can see graft has an orientation (<code>:default</code> starts at the top-left corner
like a paper sheet and <code>:graphics</code> should start at the bottom left corner like
on the chart).  Moreover, it has units. Currently, McCLIM will recognize
<code>:device</code>, <code>:inches</code>, <code>:millimeters</code> and <code>:screen-sized</code> <code>[11]</code>.</p>

<p>That said McCLIM doesn't implement graft in a useful way. Everything is measured
in pixels (which <code>:device</code> units are assumed to be) and only the <code>:default</code>
orientation is implemented. By now we should already know that pixels are a not
a good choice for the default unit. Also, programmer doesn't have means to
request unit for a sheet (this is the API problem).</p>

<p><code>[11]</code>: Screen size unit means that the coordinate [1/2, 1/2] is exactly in the
    middle of the screens.</p>

<h2>Physical size and pixel size compromise</h2>

<p>We will skip the third situation, for now, to decide what unit should we default
to. There are cognitive arguments for units based on a real-world distance but
there are also and practical reasons against using millimeters – poor mapping to
pixels and the fact that CLIM software which is already written is defined with
the assumption that we operate on something comparable to a pixel.</p>

<p>Having all that in mind the default unit should
be
<a href="https://en.wikipedia.org/wiki/Device-independent_pixel" >device-independent pixel</a>.
One of McCLIM long-term goals is to adhere
to <a href="https://material.io/" >Material Design</a> guidelines – that's why we will use
dip[6] unit. 100dp has absolute value 15.875mm. On 160dpi display it is 100px,
on 96dpi display it is 60px, on 240dpi display it is 150px etc. This unit gives
us some nice characteristics: we are rather compatible with the existing
applications and we preserving absolute distances across different screens.</p>

<p><code>[6]</code>: <a href="https://material.io/guidelines/layout/units-measurements.html#units-measurements-density-independent-pixels-dp" >Density-independent pixel</a>.</p>

<h2>How to draw a rectangle on the medium</h2>

<p>Application medium may be a pixel-based screen, paper sheet or even a text
terminal. When the programmer writes the application he operates on dip units
which have absolute value 0.15875mm. It is the McCLIM responsibility to map
these units onto the device. To be precise each graft needs to hold an extra
transformation which is applied before sending content to the display server.</p>

<p>Now we will go through a few example mappings of two rectangle borders[7] drawn
on a sheet. The violet rectangle coordinates are <code>[5,5], [22,35]</code> and the cyan
rectangle coordinates are <code>[25,10], [30,15]</code>.</p>

<ul>
<li>MDPI display device units are dip and they match native units of our
  choosing. No transformation is required.</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/mdpi.png" alt="Graft drawing" /></p>

<ul>
<li>Some old displays have density 72PPI. Not all coordinates map exactly to
  pixels - we need to round them<code>[3]</code>. Notice that border is thicker and that
  proportions are a little distorted. On the other hand despite a big change in
  resolution size of the object is similar in real-world values.</li>
</ul>

<p>Windows Presentation Foundation declared 96PPI screen's pixel being the
  device-independent pixel because such displays were pretty common on
  desktops. Almost all coordinates map perfectly on this screen. Notice the
  approximation of the right side of the violet rectangle.</p>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/72dpi-96dpi-sbs.png" alt="Lower DPI" /></p>

<ul>
<li>Fact that the screen has higher density doesn't mean that coordinates mapping
  perfectly on a lower density screen will map well to a higher density
  one. Take this HDPI screen. Almost all coordinates are floats while on the
  MDPI display they had all integer values.</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/hdpi.png" alt="HDPI" /></p>

<ul>
<li>Higher resolution makes rectangles look better (borderline is thinner and
  distortions are less visible to the eye). Here is XXXHDPI:</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/xxxhdpi.png" alt="XXXHDPI" /></p>

<ul>
<li>Some printers have a really high DPI, here is imaginary 2560 DPI printer.
  Funnily enough its accuracy exceeds our screen density so the red border which
  is meant to show the &quot;ideal&quot; rectangle is a little off (it's fine if we scale
  the image though).</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/printer.png" alt="HQ Printer" /></p>

<ul>
<li>Until now we've seen some screens with square pixels (or dots). Let's take a
  look at something with a really low density - a character terminal. To make
  the illustration better we assume an absurd terminal which has 5x8 DP per
  character (too small to be seen by a human eye). Notice that the real size of
  the rectangles is still similar.</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/console.png" alt="Character terminal" /></p>

<p>It is time to deal with <code>graphics</code> orientation (Y-axis grows towards the
top). An imaginary plotter with 80DPI resolution will be used to illustrate two
solutions (the first one is wrong!). Knowing the plotter screen height is
important to know where we start the drawing.</p>

<ul>
<li>Graft reverts Y axis and sends the image to the plotter. Do you see what is
  wrong with this picture? We have defined both rectangles in default
  orientation, so our drawing should look similar disregarding the medium we
  print on. We do preserve the real size but we don't preserve the image
  orientation – cyan rectangle should be higher on the plot.</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/plotter-wrong-sbs.png" alt="Plotter (bad transformation)" /></p>

<ul>
<li>Correct transformation involves reverting Y axis and translating objects by
  the screen height. See the correct transformation (on 80DPI and on MDPI
  plotter).</li>
</ul>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/plotters.png" alt="80DPI and MDPI plotters" /></p>

<p><code>[7]</code>: the Ideal border is composed of lines which are 1-dimensional objects
    which doesn't occupy any space. Red border in drawings marks &quot;ideal&quot; object
    boundaries. Points are labeled in device units (with possible fractions).</p>

<h2>Sheets written with a special device in mind</h2>

<p>There is still an unanswered question - how can we program applications with a
specific device limitations in mind? As we have discussed earlier default sheet
unit should be dip and default sheet orientation is the same as a paper
sheet's<code>[8]</code>.</p>

<p>Writing an application for a terminal is different than writing an application
for a web browser. The number of characters which fit on the screen is limited,
drawing shapes is not practical etc. To ensure that the application is rendered
correctly we need a special kind of sheet which will operate on units being
characters. Take a look at the following example.</p>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/sheets-different-units.png" alt="Sheets with different units." /></p>

<p>The first sheet base unit is a character of a certain physical size. We print
some information on it in various colors. Nothing prevents us from drawing a
circle<code>[9]</code> but that would miss the point. We use a character as a unit because
we don't want rounding and approximation. Background and foreground colors are
inherited.</p>

<p>The second sheet base unit is dip. It has two circles, solid grey background and
a few strings (one is written in italic).</p>

<p>Ideally, we want to be able to render both sheets on the same physical
screen. The graft and the medium will take care of the sheet approximation. The
effect should look something like this.</p>

<p><img src="https://common-lisp.net/project/mcclim/static/media/ideal-forms/screens-different-kinds.png" alt="Different kinds of screens." /></p>

<p>The first screen is a terminal. Circles from the second sheet are approximated
with characters and look ugly but the overall effect resembles the original
application. Proportions are preserved (to some degree). We see also the
terminal-specialized sheet which looks exactly as we have defined it.</p>

<p>The second screen is mDPI display. The second sheet looks very much like
something we have defined. What is more interesting though is our first sheet –
it looks exactly the same as on the terminal.</p>

<p><code>[8]</code>: Providing means to change defaults requires additional thought and is a
    material for a separate chapter. McCLIM doesn't allow it yet.</p>

<p><code>[9]</code>: As we have noted sheets are ideal planar spaces where line thickness is 0
    and there is nothing preventing us from using fractions as coordinates.</p>

<!-- Writing applications for terminal require a special kind of focus: space is -->

<!-- very limited and off-by-one errors yield a huge difference in visual appearance in -->

<!-- the application. Rounding from dip is a big no for some use cases. On the other -->

<!-- the hand we don't want to provide a separate implementation of each pane and gadget -->

<!-- (which are special kinds of sheets) in case our application declares non-default -->

<!-- units. These two concerns yield the following conclusion: in the application frame -->

<!-- different sheets may have different units and orientation (and effectively different -->

<!-- grafts engrafted to their mediums). -->

<!-- It is important to remember, that this behavior -->

<!-- must be transparent from the perspective of other sheets – we need to find a clever -->

<!-- way to convert the sheet-specific unit to the default unit dip. If a sheet is grafted -->

<!-- then this should be easy enough, but what about ungrafted sheet? What is the size -->

<!-- of a character? Also, spec clearly says, that sheet hierarchy may be grafted only -->

<!-- to one graft. Hmm, so maybe we can't really reuse the components..  -->

<!-- sheet-region is in sheet coordinate system! -->

<!-- http://bauhh.dyndns.org:8000/clim-spec/7-3.html -->

<!-- move-and-resize-sheet, sheet-transformation -->

<h1>Port and graft protocols</h1>

<p>Now we know <em>what</em> we want. Time to think about <em>how</em> to achieve it. Let me
remind you what kind of objects we are dealing with:</p>

<ul>
<li><p>Port is a logical connection to a display server. For instance, it may contain
  a foreign handler which is passed to the external system API. It is
  responsible for the communication – configuring, writing to and reading<code>[10]</code>
  from a device, we are connected to.</p></li>
<li><p>Graft is a logical screen representation on which we draw. It is responsible
  for all transformations necessary to achieve the desired effect on the
  physical screen. The same port may have many associated grafts for
  applications with different units and orientations.</p></li>
<li><p>Medium is a representation of the sheet on a physical device. Sheet is the
  Form which is a region and may be drawn – it doesn't concern itself with
  physical limitations.</p></li>
</ul>

<p>In the next post I will show how to implement the port and the graft (and a bit
of the medium) for the charming backend. I will cover only bare minimum for
mediums important to verify that graft works as expected. Complete medium
implementation is the material for a separate post.</p>

<p><code>[10]</code>: Sometimes we deal with devices which we can't take input from – for
    instance a printer, a PDF render or a display without other peripherals.</p>
 ]]></description> </item><item> <title>McCLIM 0.9.7 &quot;Imbolc&quot; release</title> <link>https://common-lisp.net/project/mcclim/posts/McCLIM-097-Imbolc-release.html</link> <pubDate>2018-02-16 16:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/McCLIM-097-Imbolc-release.html</guid>  <description><![CDATA[ <p>After 10 years we have decided that it is time to make a new release – the first
one since 2008, which was McCLIM 0.9.6, <em>St. George's Day</em>. <em>Imbolc</em> is a Gaelic
traditional festival marking the beginning of spring held between the winter
solstice and the spring equinox.</p>

<p>Due to a long period of time, the number of changes is too big to list in full
detail and we will thus note only major changes made during the last eleven
iterations (though many important changes were done before that). For more
information please check out previous iteration reports
on <a href="https://common-lisp.net/project/mcclim/1.html" >McCLIM blog</a>,
<a href="https://github.com/robert-strandh/McCLIM/commits/master" >git log</a> and
the <a href="https://github.com/robert-strandh/McCLIM/issues" >issue tracker</a>. We'd like
to thank all present and past contributors for their time, support and testing.</p>

<ul>
<li>Bug fix: tab-layout fixes.</li>
<li>Bug fix: formatting-table fixes.</li>
<li>Bug fix: scrolling and viewport fixes and refactor.</li>
<li>Feature: raster image draw backend extension.</li>
<li>Feature: bezier curves extension.</li>
<li>Feature: new tests and demos in clim-examples.</li>
<li>Feature: truetype rendering is now default on clx.</li>
<li>Feature: additions to region, clipping rectangles and drawing.</li>
<li>Feature: clim-debugger and clim-listener improvmenets.</li>
<li>Feature: mop is now done with CLOSER-MOP.</li>
<li>Feature: threading is now done with BORDEAUX-THREADS.</li>
<li>Feature: clx-fb backend (poc of framebuffer-based backend).</li>
<li>Feature: assumption that all panes must be mirrored has been removed.</li>
<li>Cleanup: many files cleaned up from style warnings and such.</li>
<li>Cleanup: removal of PIXIE.</li>
<li>Cleanup: removal of CLIM-FFI package.</li>
<li>Cleanup: changes to directory structure and asd definitions.</li>
<li>Cleanup: numerous manual additions and corrections.</li>
<li>Cleanup: broken backends has been removed.</li>
<li>Cleanup: goatee has been removed in favour of Drei.</li>
<li>Cleanup: all methods have now corresponding generic function declarations.</li>
</ul>

<p>We also have a bounty program financed with money from the fundraiser. We are
grateful for financial contributions which allow us to attract new developers
and reward old ones with bounties. Currently active bounties (worth $2650) are
available <a href="https://www.bountysource.com/teams/mcclim/bounties" >here</a>.</p>

<p>As <em>Imbolc</em> marks the beginning of spring we hope this release will be one of
many in the upcoming future.</p>
 ]]></description> </item><item> <title>Progress report #11</title> <link>https://common-lisp.net/project/mcclim/posts/Progress-report-11.html</link> <pubDate>2018-01-27 15:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Progress-report-11.html</guid>  <description><![CDATA[ <p>Dear Community,</p>

<p>After three months of work, we are happy to present this progress report.</p>

<p><strong>Some highlights for this iteration</strong>:</p>

<ul>
<li>numerous bug fixes (and some regressions introduced)</li>
<li>graphics state has been factored into its own class hierarchy</li>
<li>clipping region may be an arbitrary region (not only a rectangle)</li>
<li>draw-design works correctly now for ellipses and patterns</li>
<li>major region code improvements including better coverage of <code>region-intersection</code>, <code>region-contains-position-p</code>, support for unsupported yet pairs (i.e <code>standard-rectangle</code> vs <code>bounding-rectangle</code>, <code>standard-ellipse</code> vs <code>standard-rectangle</code> and many others)</li>
<li>complete implementation of ellipsis with limited angles and rotations (region code <em>and</em> rendering)</li>
<li>numerous UX improvements for <code>text-field</code>, <code>describe</code>, <code>drag-and-drop</code>, scrolling, <code>compose-space</code>, <code>resize-sheet</code>, <code>clim-debugger</code> and <code>listener</code></li>
<li><code>:pane</code> option in <code>define-application-frame</code> is more useful now</li>
<li><code>clim-formatting-table</code> code major refactor. One of the results is that borders may wrap table cells, columns and rows appropriately</li>
<li>drawing tests cleanups, improvements, and additions.</li>
</ul>

<p>Some work has been done to improve CLX library. We have added a test suite and fixed its working on CCL (which had some problems with it). Thanks to that McCLIM works on CCL way faster than before (around 3x – subjective). We were also able to make <a href="https://gitlab.common-lisp.net/mcclim/gramps-clim2" >CLIM-TOS</a> (Franz's CLIM 2 fork) start simple applications on CCL and SBCL. I'm mentioning this because some people are not fond of McCLIM license and fact that we have two FOSS implementations of the same standard may be yet another good reason to start writing applications in CLIM.</p>

<p><strong>Bounties</strong>:</p>

<p>All McCLIM bounties (both active and already solved) may be found
<a href="https://www.bountysource.com/teams/mcclim/bounties" >here</a>. Default
bounty expiration date is 6 months after publishing it (a bounty may be
reissued after that time period).</p>

<p><strong>Bounties solved this iteration</strong>:</p>

<ul>
<li>[$100] drag-test demo: dragging square to the empty position invokes the debugger</li>
<li>[$100] Text field pane height is too small, clipping the bottom of characters</li>
</ul>

<p><strong>Active bounties</strong> ($1600):</p>

<ul>
<li>[$300] Listener: repl blocks when long process runs</li>
<li>[$500] Windows Backend</li>
<li>[$400] Fix Beagle backend</li>
<li>[$150] When flowing text in a FORMATTING-TABLE, the pane size is used instead of the column size</li>
<li>[$150] clx: input: english layout</li>
<li>[$100] Add PDF file generation (PDF backend)</li>
</ul>

<p>Our current financial status is $2014 for bounties and $288 recurring
monthly contributions from the supporters (thank you!).</p>

<p>Suggestions as to which other issues should have a bounty on them are
appreciated and welcome. Please note that Bountysource has a
functionality &quot;Suggest an Issue&quot; which may be found on the
<a href="https://www.bountysource.com/teams/mcclim/bounties" >bounties</a>
page. If you would like to work on an issue that is not covered by the
existing bounties, feel free to suggest a new bounty.</p>

<p>During this quarter we have noticed more interest in learning CLIM and developing
applications with it among fellow Common Lisp programmers.</p>

<p>If you have any questions, doubts or suggestions – please contact me
either by email (daniel@turtleware.eu) or on IRC (my nick is
<code>jackdaniel</code>). McCLIM developers and users hang out on <code>#clim</code> IRC
channel on Freenode.</p>

<p>Sincerely yours,<br/>
Daniel Kochmański</p>

<p>Here are some screenshots made in the meantime which are related to the changes:
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/ellipsis.png" alt="Ellipsis" title="Ellipsis"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/ellipsis2.png" alt="Ellipsis 3" title="Ellipsis"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/ellipsis3.png" alt="Ellipsis 2" title="Ellipsis"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/scroll.jpeg" alt="Scroll notes" title="Scroll notes"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/slope-lines.png" alt="Slope lines" title="Slope lines"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/slope-lines2.png" alt="Slope lines 2" title="Slope lines"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/table.png" alt="Bordered table" title="Bordered table"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/table2.png" alt="Bordered table 2" title="Bordered table"/>
<img src="https://common-lisp.net/project/mcclim/static/media/it-11/clim-tos.jpeg" alt="Address Book demo" title="McCLIM and CLIM TOS"/></p>
 ]]></description> </item><item> <title>Progress report #10</title> <link>https://common-lisp.net/project/mcclim/posts/Progress-report-10.html</link> <pubDate>2017-10-22 16:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Progress-report-10.html</guid>  <description><![CDATA[ <p>Dear Community,</p>

<p>We have many important improvements since the last iteration and even
more work is pending. I want to apologise for this late progress
report – it has been almost three months since the last update. I'll
try to improve in this regard.</p>

<p><strong>Some highlights for this iteration</strong>:</p>

<ul>
<li>various utilities have been replaced with <code>alexandria</code> equivalents</li>
<li>distinct frames don't shadow <code>*accelerator-gestures*</code> of their children</li>
<li>accepting-values refinements - better handling of errors and return values</li>
<li>refactor and small fixes of the recording implementation code</li>
<li>refinements in class hierarchy for streams, medium  and graphics state</li>
<li>slider from 30.4.5 spec section has been implemented</li>
<li>scrolling implementation refinements</li>
<li>tab-layout extension refactor</li>
<li>improvements related to <code>drei</code> text editing substrate</li>
<li>user manual refinements and improvements of its building scripts</li>
<li>improvements related to the PDF backend</li>
<li>MOP code has been ported to use <code>closer-mop</code> portability layer</li>
<li>numerous editorial fixes in bundled specification sources</li>
<li>improvements to <code>format-graph-from-roots</code></li>
<li>better Unicode support in CLX for frame title</li>
<li>general code base cleanup to decrease number of warnings during compilation</li>
<li>transparency handling in CLX backend and alpha channel support in images</li>
<li>small Listener improvements (bug fixes and cleanups)</li>
</ul>

<p>We want to thank everybody who has contributed to the project (by
improving the code base, discussions, issue reporting, providing advice
and suggestions, monetary contributions etc). We are especially
grateful to the following people: Nisar Ahmad, Alastair Bridgewater,
John Carroll, Cyrus Harmon, Philipp Marek, Elias Mårtenson, Piotr
Mieszkowski, Jan Moringen, Nick Patrick, Alessandro Serra and last but
not least Robert Strandh.</p>

<p><strong>Bounties</strong>:</p>

<p>All McCLIM bounties (both active and already solved) may be found
<a href="https://www.bountysource.com/teams/mcclim/bounties" >here</a>. Default
bounty expiration date is 6 months after publishing it (a bounty may be
reissued after that time period).</p>

<p><strong>Bounties solved this iteration</strong>:</p>

<ul>
<li>[$300] Replace MOP things with closer-mop portability layer</li>
<li>[$100] Keystroke accelerators may shadow keys even if inactive</li>
</ul>

<p><strong>Active bounties</strong> ($1800):</p>

<ul>
<li>[$100] drag-test demo: dragging square to the empty position invokes the debugger (<em>new</em>)</li>
<li>[$100] Text field pane height is too small, clipping the bottom off characters (<em>new</em>)</li>
<li>[$300] Listener: repl blocks when long process runs (<em>new</em>)</li>
<li>[$500] Windows Backend</li>
<li>[$400] Fix Beagle backend</li>
<li>[$150] When flowing text in a FORMATTING-TABLE, the pane size is used instead of the column size</li>
<li>[$150] clx: input: english layout</li>
<li>[$100] Add PDF file generation (PDF backend)</li>
</ul>

<p>Our current financial status is $1089 for bounties and $264 recurring
monthly contributions from the supporters (thank you!).</p>

<p>I have been asked a question about who decides which issues have
bounties on them and how the reward amounts are decided. If anyone has
been wondering about the same here goes the answer: issues and prices
are based on my subjective opinion indicated by problems users
encounter and what I consider being worth putting bounty on it. Note
though, that I'm open to suggestions (see the next paragraph). I hope
that despite some potential doubts the community is generally
satisfied with the progress and decisions we make. If there is some
lack of transparency, please let me know what you want to know and
I'll do my best to help.</p>

<p>Suggestions as to which other issues should have a bounty on them are
appreciated and welcome. Please note that Bountysource has a
functionality &quot;Suggest an Issue&quot; which may be found on the
<a href="https://www.bountysource.com/teams/mcclim/bounties" >bounties</a>
page. If you would like to work on an issue that is not covered by the
existing bounties, feel free to suggest a new bounty.</p>

<p>If you have any questions, doubts or suggestions – please contact me
either by email (daniel@turtleware.eu) or on IRC (my nick is
<code>jackdaniel</code>). McCLIM developers and users hang out on <code>#clim</code> IRC
channel on Freenode.</p>

<p>Sincerely yours,<br/>
Daniel Kochmański</p>
 ]]></description> </item><item> <title>Progress report #9</title> <link>https://common-lisp.net/project/mcclim/posts/Progress-report-9.html</link> <pubDate>2017-07-29 17:00</pubDate> <author>Daniel Kochmański</author> <guid isPermaLink="true">https://common-lisp.net/project/mcclim/posts/Progress-report-9.html</guid>  <description><![CDATA[ <p>Dear Community,</p>

<p>McCLIM code is getting better on a weekly basis depending on developer
time. We are happy to see the project moving forward.</p>

<p><strong>Some highlights for this iteration</strong>:</p>

<ul>
<li>Scigraph code cleanup and bug fixes,</li>
<li>Bezier curves improvements,</li>
<li>PostScript and PDF improvements,</li>
<li>CLX-fb and mcclim-renderer speed improvements and refactor,</li>
<li>various code cleanups from unused and broken constructs,</li>
<li>editorial corrections to the CLIM 2 specification sources we bundle
with McCLIM</li>
</ul>

<p>Moreover many bug fixes have been proposed and merged into the
codebase.</p>

<p>All McCLIM bounties (both active and already solved) may be found
<a href="https://www.bountysource.com/teams/mcclim/bounties" >here</a>. Default
bounty expiration date is 6 months after posting it (a bounty may be
reissued after that time period).</p>

<p>To answer recurring requests for native Windows and OSX support, we
have posted bountes for finishing the Windows backend and fixing the
OSX backend. Moreover, to improve portability a bounty for closer-mop
support has been posted.</p>

<p><strong>Bounties solved this iteration</strong>:</p>

<ul>
<li>[$100] Caps lock affects non-alphabetic keys.</li>
</ul>

<p><strong>Active bounties</strong> ($1700):</p>

<ul>
<li>[$500] Windows Backend (<em>new</em>).</li>
<li>[$400] Fix Beagle backend (<em>new</em>).</li>
<li>[$300] Replace MOP things with closer-mop portability layer (<em>new</em>).</li>
<li>[$150] When flowing text in a FORMATTING-TABLE, the pane size is
  used instead of the column size.</li>
<li>[$150] clx: input: english layout.</li>
<li>[$100] Add PDF file generation (PDF backend).</li>
<li>[$100] Keystroke accelerators may shadow keys even if inactive.</li>
</ul>

<p>Our current financial status is $800 for bounties and $267 recurring
monthly contributions from the supporters (thanks!).</p>

<p>Suggestions as to which other issues should have a bounty on them are
appreciated and welcome. Please note that Bountysource has a
functionality &quot;Suggest an Issue&quot; which may be found on the
<a href="https://www.bountysource.com/teams/mcclim/bounties" >bounties</a>
page. If you would like to work on an issue that is not covered by the
existing bounties, feel free to suggest a new bounty.</p>

<p>If you have any questions, doubts or suggestions – please contact me
either by email (daniel@turtleware.eu) or on IRC (my nick is
<code>jackdaniel</code>).</p>

<p>Sincerely yours,<br/>
Daniel Kochmański</p>
 ]]></description> </item> </channel> </rss>