Lispworks' manual said non-focus window is some kind of window that not taking focus, but in fact any interface can work without focus anyway :)... I just treat it as a way to raise windows without system's decorations like border & action buttons. We will get it done using floating divs in web-based UI, but they usually have some limitations like not support to display out of the DOM, and such a native window can hold these situation very well. That's the advantage of native framework.

LW has exported 2 interface to raise non-focus window, one is capi:prompt-with-list-non-focus, to raise a list panel, and another is capi:display-non-focus-message, to raise a display pane with certain string. Besides these two types, there is an internal capi::display-non-focus-editor-pane can be used - although lacking in arglist description, but can still work with those known arguments from other two functions. The non-focus editor pane is exactly what have been used in the Function Arglist Displayer.

And, we can raise an arbitrary interface by directly instanciate a capi::non-focus-interface. Two initargs :previous-x and :previous-y are necessary as the relative position of its owner. The gesture-callbacks should be used for capi:non-focus-maybe-capture-gesture. Interface arguments like window-styles can be used to make more precise effects.

(capi:display
 (make-instance 'capi::non-focus-interface
                :window-styles '(:borderless)
                :layout (make-instance
                         'capi:column-layout
                         :description
                         (list (make-instance 'capi:display-pane
                                              :text "test")))
                :previous-x 0 :previous-y 0)
 :owner (editor:window-text-pane (editor:current-window)))

The documented way to update items in non-focus-list-interface is using list-updater, this function should return new items or destroy, and the interface will be repositioned and resized to fit its children using its positioning-function. It's a undocumented keyword for all of those raising functions. CAPI have given an default one of this slot, so we can know this function should take the interface itself, then directly move it, with no return value (probably). But we can also set the top-level interface geometries of the interface directly. Sometimes the coordinates need to be converted from the screen to the owner, and capi:convert-relative-position can be used.

Sometimes there are still some effect not satisfy our needs, like the selection of non-focus-list-interface will be reset after items update. Directly accessing the components using capi::non-focus-interface-list-panel etc. can be used to achieve complex manipulates.

The redisplay of non-focus-interface have been forced to happen in the owner's process, and this may cause annoying laggings of UI process sometimes. I will just start a thread to prepare all datas needed, then calling for GUI update using apply-in-pane-process. Sometimes it's still useless when we raise/move window rapidly, and the native handler itself is laggy enough though. Attaching the non-focus interface to a standalone process may works.