Что на данный момент с гуем для CL? Какие гуй-библиотеки можно назвать современными, не сырыми и кроссплатформенными? 

Все сырые. Разве только LTK не сырая из-за своей примитивности.
CL-GTK2 -- только GTK+ 2.0; не развивается;
RDNZL -- убог;
EQL -- "no CLOS/no GC" :D;
Если нужна кроссплатформенность и CL, то альтернатив CL-GTK2 я не вижу.
Если только Windows, то я бы написал с CFFI свою библиотеку-обёртку над WinAPI.

>CL-GTK2 -- только GTK+ 2.0; не развивается;

Кстати, а есть ли желающие развивать cl-gtk2?

есть желающие использовать!) Если разивать, то порог вхождения, видимо, слишком велик, ведь были же желающие 

Мне кажется, CL-GTK2 надо разбивать на части. Выделить отдельно GLib. Прикрутить GobjectIntrospection. Нужно добиться, чтобы всё генерировалось из GIR, пусть и ценой отказа от обратной совместимости. Иначе иметь полноценный биндинг к GTK+ не получится, из-за очень скромного комьюнити CL. GTK3 уж на дворе...

Есть желание, знаний не хватает. Как можно с вами связаться?

А таки mcclim не стоит использовать? Он вроде имеет привязку к cairo.

Он вроде заброшенный. Но кое-какие вещи на нём писались, веб-браузер Closure, например.

Ага. И редактор с непристойным названием. :)

Судя по скроллбарам, статусбару, шрифтам вроде ничего.
http://jlr.freeshell.org/data/mcclim/screenshots

Сносно, но чужеродно на всех системах. Для windows это может и не проблема, там к такому привыкли, но вот линуксоиды и особенно маководы такого не потерпят.

вот кстати, чтобы и здесь лежало.
ссылка не порт cl-gtk2 на gtk3.
http://common-lisp.net/project/gtk-cffi/

как его выкачать?
кстати, есть ещё github.com/Ramarren/cells-gtk3, вроде живой

cvs -z3 -d :pserver:anonymous:anonymous@common-lisp.net:/project/gtk-cffi/cvsroot co gtk-cffi

Хотелось спросить вопрос, а стоит ли так гнаться за GTK?
Выгоднее ли иметь готовый фреймворк, который просто содержит разные бэкэнды рисования и обработки сообщений? Да, конечно, в этом случае получится ненативный вид приложения.

> стоит ли так гнаться за GTK?
GTK и есть тот самый фреймворк с разными бэкендами. Строить бэкенд над GTK -- уподобляться wxWidgets.
Можно сделать что-то своё, но тут проблема с объёмом работы. В windows можно использовать WinAPI и готовые виджеты (ActiveX, не к ночи будь помянут).
В *nix нету ничего подобного. Нет такой lungua franca для GUI. Приходится изобретать всё заново, либо брать готовый фреймворк.
Почему именно GTK?
Наверное потому, что с ним меньше всего проблем в плане интеграции с другими языками. GLib/GObject/GTK разрабатывают с оглядкой на Python. GIR тот же делают. Намного больше шансов не застрять на полпути.

> Строить бэкенд над GTK -- уподобляться wxWidgets.
А что не так с wxWidgets? ;) Кстати, wxCL же. Там, конечно, особо жизни никогда не было, но работало вроде как-то когда-то. Допилить и вперёд.

> А что не так с wxWidgets?
Неохота повторяться. Тут уже писал:
http://www.linux.org.ru/forum/development/6710666/page1#comment-6713755
http://www.linux.org.ru/forum/development/6710666/page2?lastmod=1315820719273#comment-6717725
http://www.linux.org.ru/forum/development/6710666/page2?lastmod=1315820719273#comment-6718567

Я, конечно, всеми руками за gtk, но, честно говоря, после небольшого erp велосипеда на Qt понял, что броузер + jQuery + lisp вполне себе достойны внимания. Я к чему клоню, может ТС достаточно web'а?

тут зависит от прихоти заказчика, а большинство из них обычные люди, с обычным нежеланием пробовать что-то новое, вот и подавай им привычный гуй

как вас там зовут? эти ссылки не работают
последняя активность wxCL - 2009

> как вас там зовут? эти ссылки не работают
k_andy

Да, гуй через браузерные технологии сейчас весьма актуален. jQuery имею счастье владеть - очень мощный фреймворк со всеми необходимым компонентами в ui и охренительной кучей компонентов созданных сторонними разработчиками. Приличный дизайн у этого фреймворка (несмотря на то что попса). А там можно и CL либу parenscript для javascript'a использовать при необходимости (но генерить javascript, правда, не очень хорошо по некоторым причинам, например - осложняет отладку). И для CL есть парсеры json'a (да и парсеры XML имеются), с шаблонизаторами тоже всё ок. К тому же есть технологии упрощающие использование браузерных движков, то есть можно web-приложение поставлять заказчику как десктопное для него разницы (в использовании и визуально) не будет никакой. + не надо специально создавать веб-аналог при необходимости. На одной фирме сам видел такой подход - то что, приложение создана на базе браузера вообще не было видно. + это вообще современный подход, пример та же windows8 ... а если использовать CL для декларативного описания GUI а-ля CAPI, а все html/css/javascript/jquery дела убрать в background и прикрутить какие-нибудь хитрые механизмы отладки к лисп-инструментам, так вообще было бы шоколадно!!!

> ... гуй через браузерные технологии...
Это слишком сложно для цирка.
Такой подход оправдан для больших программ, где накладные расходы на браузер незаметны. И тоже не для всяких больших программ. Имакс на браузере не сделаешь, максимум -- опердень.

Типа имакс на браузере где-то видел мельком. Смотря для каких больших, если нужен о-очень сильно навороченный гуй, то именно в накладных расходах (в варианте с браузером) может быть проблема. И то спорно, сейчас очень интенсивно развивается в браузерах аппаратное ускорение вывода графики и компиляция javascript. Но я не утверждаю, что необходимость в нативном гуй очень сильно пропадёт. Есть свои плюсы и минусы в обоих подходах.

Дело не в навороченности. Тут как раз наоборот, html/css/js позволяют намного больше. И для опердени браузер -- идеал.
Я говорю про overhead для небольших программ. Не станете же вы писать блокнот/калькулятор таким образом. Не поймут-с.

> Не станете же вы писать блокнот/калькулятор таким образом.
Ну если вспомнить сколько памяти хавает SBCL (да и другие реализации) просто по факту своего запуска, то может вообще не стоит думать о разработке подобного софта на CL? Просто даже при наличии хорошей графической библиотеки использовать CL для простых программ как-то не очень разумно, не, ну для себя, конечно, можно.

Хавает не много (терпимо). Вот размер бинарника выходит чудовищным.
_{(Попробовал сегодня скомпилировать свою поделку свежим SBCL 1.0.52 и охуел, 127 мегабайт.)}

А я считаю, что CL можно и нужно использовать для всего.
Все программы когда-то были маленькими и простыми.

Вот по этому поводу новость

SBCL now supports compressed cores

http://xach.livejournal.com/295584.html

gzexe и до этого был. И не устраивал тем, что очень сильно замедлял запуск.

и тем, что не уменьшал потребление RAM

compression тоже не уменьшает потребление RAM

я и не спорю, поэтому и нужен tree-shaker

А что такое GIR? некая метаинформация об API?
И вот еще может перенять опыт и попросить сообщество профинансировать проект cl gtk3?
Для sbcl вот баснословные деньги насобирали, по меркам моего местопроживания.

Странно что gzexe замедлял запуск. В эпоху интенсивного развития пакеров главная идея была как раз в быстром запуске, ведь читать с жёсткого диска долго, а развернуть в памяти можно достаточно быстро. Так что информацию следует уточнить.
Насчёт cl gtk3 - да не знаю, какой лисп-проект связанный с gtk созрел для этого. Может апгрейдить cl-gtk2 до cl-gtk3 самое простое решение? Думаю, у тех кто работал с cl-gtk2 есть какие-то мнения на этот счёт.
А tree-shaker нужен, да. Кроме эстетического удовольствия от созерцания небольшого размера исполняемого файла, уверен найдутся полезные применения.

В CL-GTK2 достаточно развит gobject, а всё остальное не поспевает за мэйнстримом. Вот я и думаю, что неплохо бы обособить cl-gtk2-glib и привинтить gir. Кое-какие наброски для gir у меня есть (уже второй заход делаю), но времени как-то не хватает чтобы родить что-то путнее.

А что такое GIR?

GObjectIntrpospection.

Я и имел ввиду апгрейд cl-gtk2.
т.е. GIR позволит генерировать весь остальной код, который сейчас сделан руками в cl-gtk2?

> т.е. GIR позволит генерировать весь остальной код, который сейчас сделан руками в cl-gtk2?
Ну не точно такой же. Но подобный. Некоторые части cl-gtk2-gtk сделаны не как калька с C API, а "лиспифицированы".
Мало того, GIR открывает дорогу ко всему Gnome-стеку. Тут и gstreamer и evince и telepathy и clutter и неродные для Gnome библиотеки: Xlib, libxml2, freetype, GL (эти могут быть неполными).

Э-эх!
https://github.com/andy128k/cl-gobject-introspection
Может кто присоединится, или форкнет? Или вдохновится и доведёт до конца?

А вот еще кто-то делает
http://bazaar.launchpad.net/~scymtym/+junk/cl-gir/files

Мое мнение такое, что покуда у лиспов нет мега-гуи-фреймворков уровня WPF или хотя бы винформс, то единственный вариант гуи - родная библиотека виджетов платформы/операционной системы, на которой лисп работает, через FFI.
Для винды, это, естественно, означает winapi и COM, для яблочных платформ - Cocoa. Для линуксов и прочих поделок я не знаю зачем GUI нужен, ну если приперло, то можно запилить веб-гуи, наверное.
Можно возразить за кроссплатформенность, конечно, но я считаю, что кроссплатформенность на самом деле нафиг не нужна; в 90% случаев это просто маркетоидный баззворд, а в оставшихся 10% - "как сделать чтобы моя гуевая поделка написанная в линуксах работала на винде или макоси"(пишите сразу для винды/макоси, блин, вот как).

RDNZL нормально так работает, если не выходить за пределы "дернем пару дотнетовых классов по мелочи", но в качестве полной интеграции рантаймов лиспа и дотнета он плоховат, да. Плюс, 4й фреймворк где-то в области сборщика мусора не особо сильно дружит с лисповыми рантаймами.

кстати, такая подсказка всем использующим .NET и COM в лиспах, через RDNZL или как еще:
1) Windows.Forms и WPF, и некоторые другие компоненты .NET, требуют инициализации треда в STA. При этом они предполагают, что некоторый отдельный тред свой апартамент сменить после его установки не может. Поэтому _никогда_ не запускайте их в главном лисповом треде, особенно в REPL(это еще кстати и по причине 2).
2) Ни в коем случае не запускайте дотнетовые компоненты, использующие виндовый цикл сообщений в треде, использующем блокирующее IO, в частности, ни в коем случае нельзя их запускать в треде с лисповым REPL, т.к. при таком раскладе все обычно заканчивается сегфолтом, или чем похуже, где-нибудь в недрах .NET или лиспового рантайма, с последующей смертью лиспового процесса. 

> что с гуем для свободных лисп-реализаций?

хреново, к сожалению. Ситуация, по видимому, не исправится в ближайшее время, потому что ГУЙ нужен здесь и сейчас. Поэтому лучше херней не заниматься, купить LispWorks и использовать CAPI с его нативным интерфейсом под все распространенные ОС, написать наконец продукт, и радоваться полученному профиту. 

> Какие гуй-библиотеки можно назвать современными, не сырыми и кроссплатформенными?

никакие

на халяве далеко не уедешь. правда жизни, че. :)