Опубликован проект RubyWM, развивающий оконный менеджер на базе протокола X11, написанный на языке Ruby, включая драйвер для работы с протоколом X11. RubyWM поддерживает виртуальные рабочие столы и может использовать как мозаичную (tailing) компоновку окон, так и произвольное позиционирование окон на рабочем столе. Код RubyWM распространяется под лицензией MIT. Проект также развивает библиотеку pure-X11 с реализацией протокола X11 на языке Ruby...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60481
у меня только один вопрос - зачем? академический интерес?
Думаю, потому что может. Интересно же.
Скорее, потому что учится программированию. Человек, который "может", заниматься подобным не стал бы.
А чем бы стал?
на работу бы устроился.
Это кто-то из Анонимов Опеннет устал проклинать Wayland и взял поддержку X в свои руки.
Это очень хороший и интересный вопрос, который вообще говоря можно было бы расширить до "зачем в открытый сырец"?
Что мотивирует людей писать код вместо почесывания своих или даже чужих частей тела.
Ответ многогранен и неоднозначен, но он есть, и вполне себе обоснован.
Во-первых зачастую подобная профтрансформация начинается после определённого количества лет работы с одним и тем же стэком, когда этот Руби-буби или что там ещё начинает отскакивать от зубов с нулевой затратой мозг-ресурса. То есть можно просто вот так вот сесть и за 15 минут запилить ещё один кормит не напрягаясь.
Что касается мотивации, то тут есть несколько моментов.
Когда работаешь в команде, тебе приходится считаться с верованиями ещё н-прогеров, с которыми ты конечно же несогласен в 50% решений. В твоём проекте ни с кем считаться не нужно, и это даёт дорогу, то есть практику твоим собственным идеям. После обкатки их в своём проекте ты уже можешь уверенно применить их и в прадакшане.
Далее есть карьерный момент - портфолио. Представь что есть компания Х, которая очень ищет рубиста, ну или на это автор сабжа небезосновательно рассчитывает.
- Какие ваши доказательства?
- запилил Х11 менеджера
- когда сможете приступить к работе?
Вот элементарная ситуация - нужен тимлид или СТО, в общем ищут босса. Такое бывает если предыдущей сбежал.
Котлета предлагается сочная, соответственно на неё слетаются всякие шарлатаны с которыми нужна канкуриравать.
А тут у тебя проектик под ключ с сиай, релизами, тестами, весь код красиво, под платформы там, популярно, и ты такой хоп, сматрите, я вам так же сделаю, только дайте мне деньге и власть
> Вот элементарная ситуация - нужен тимлид или СТО, в общем ищут босса.
> Такое бывает если предыдущей сбежал.
> Котлета предлагается сочная, соответственно на неё слетаются всякие шарлатаны с которыми
> нужна канкуриравать.
> А тут у тебя проектик под ключ с сиай, релизами, тестами, весь
> код красиво, под платформы там, популярно, и ты такой хоп, сматрите,
> я вам так же сделаю, только дайте мне деньге и властьПримечательно, что это заодно объясняет повторяющиеся в каждой теме вопросы "кому оно надо" и вообще высокий уровень энтропии в комментариях. Шарлатанам ведь тоже нужна канкурировать.
Первый шаг сделан, теперь ждем мобильную ось Рубироид.
Уже почти мерещатся обсуждения о добавлении Руби в ядро.. :)
Нет, в целом идея норм, если скриптовый интерпретатор шустрый и грамотно спроектированный.Но руби… М–м–м, тормоза–а–а…
> скриптовый интерпретатор шустрый и грамотно спроектированныйпитон, питон и ещё раз питон))
Не настолько Руби тормозной, чтоб это было заметно в GUI-задачах. К тому же, в последних версиях производительность сильно выросла. Хотя, для некоторых и Qt тормозной.
Yast2 в opensuse на руби, работает отвратительно. UI подвисает при загрузке из сети, многопоточки нет.
Это проблема не языка, а быдла которое разрабатывает сусе
На руби многопоточка делается с закрытыми глазами. То что в ясте не осилили - проблемы яста.
>Но руби… М–м–м, тормоза–а–а…Уже давно не так https://www.opennet.me/opennews/art.shtml?num=60384
Да и задача не требует скорости, всё в ввод-вывод упирается.
Давно, и всё ещё так. Везде, где руби показывает хоть какие-то приличные результаты относительно всего цеха, при детальном рассмотрении оказываются манипуляциями с условиями работы, которых в реальных практических задачах практически нет.
Ты всегда можешь провести свои тесты) По моим руби точно быстрее питона, как минимум.
По ссылке результаты получше перла (что ожидаемо) и похуже пхп. Даже не знаю что могло бы быть хуже... какой-нибудь shell только.
А то, что по ссылке Руби получше Питона, Вы предпочли не замечать?
Интересно как так получается, что Ruby быстрее, только софту на Ruby со старта требуется вагон ресурсов, в то же время как Django со всеми его батарейками может нормально жить даже на каких-нибудь одноплатниках.
> Софту на Ruby со старта требуется вагон ресурсовКакое наглое враньё. Сразу видно, что Руби вы в глаза не видели.
>> Софту на Ruby со старта требуется вагон ресурсов
> Какое наглое враньё. Сразу видно, что Руби вы в глаза не видели.Бгг. Один Gitlab чего стоит.
>>> Софту на Ruby со старта требуется вагон ресурсов
>> Какое наглое враньё. Сразу видно, что Руби вы в глаза не видели.
> Бгг. Один Gitlab чего стоит.И что, Гитлабу какой-то вагон ресурсов требуется? Пользовался Гитлабом, что-то не заметил такого. А какой-нибудь Jira надо меньше ресурсов что ли? Или какой-нибудь Oracle ресурсов не требует?
И вообще-то речь про другое шла. Было высказано утверждение, что неуказанному, а значит любому софту на Руби требуется вагон ресурсов. Даже хелловорлду. То есть в Руби якобы какой-то очень уж ресурсожрущий рантайм. Так вот это наглое враньё.
> И что, Гитлабу какой-то вагон ресурсов требуется?Ну попробуй взять VPS за 5 баксов и развернуть на ней гитлаб. Даже для себя самого, без сотни-другой пользователей. Или какой-нибудь почивший Portus.
> А какой-нибудь Jira надо меньше ресурсов что ли?
Беспроигрышный вариат: сравнить с джавой. В этом случае что угодно будет жрать меньше.
> Было высказано утверждение, что неуказанному, а значит любому софту на Руби требуется вагон ресурсов. Даже хелловорлду.
Ресурсопотреблением хелловорлдов на руби никогда не интересовался.
Его реальное использование сводится к Ruby On Rails практически без погрешности.
чувак, ты до сих пор учишься по видосам блогеров 10 летней давности как писать hello word?
уже давно перешел на hello excel и hello powerpoint
С одной стороны - именно у GUI-приложений есть достаточно четко определенные метрики по скорости работы, с другой - с т.з. IT они вполне себе лояльные...
Интересно, на OpenBSD заводится?
Опять вопросы от анонимов. Зачем? Новость под тегом #ненужно или #нужно? И так далее.Ответ прост.
Автор загорелся некой идеей, реализовал ее на практике на том, что знал и поделился с другими. На этом всё.
Если не полениться, и глянуть по ссылке в github, то там все написано
Анонимы по ссылкам не ходят и живут по правилу "Не читал, но свое мнение по этому непрочитанному я до Вас донесу!"
Какой второй вариант развития событий?
Переписать на PHP.
Ответ на QTile?)
Очень своевременно WM для X-ов
Руби...м-м-м, ня-яшка :*Нужно!
Занятная штука.
Уже есть оконный менеджер на Ruby, есть оконный менеджер на Rust, осталось сделать на R!
Было бы приколько собрать все ссылки на проекты, чтобы для каждого языка был свой оконный велосипед)
На Matlab.
На матлабе не знаю, а вот на фортране такое 100% есть.
Ещё пока нет для каждого языка своей DE.
В начале нулевых было крайне модно писать ВМ. Сейчас нет, ВМ умирают.
На htlm+css only.
От это веселуха будет, столько каках посыпится, зато скорость... )))
Какой амбулаторий..
Выглядит вырвиглазно, как и весь опенсорс!
а композитор wayland на ruby можно написать?
разрешаю, пиши!
Этим займешься именно ТЫ!
Но сначала библиотеку pure-Wayland с реализацией протоколов Вяленого на языке Ruby.
Почему нет? Берешь протокол, реализуешь. Это кстати было бы интересней, чем ВМ.
Твм на руби, заманчиво.
РубоГном!
Выглядит как c++ с синтаксисом руби
Представлен новый оконный менеджер, и .. сразу на Иксах. Вэйланда нет.
Wayland в силу ряда причин существенно уступает иксам
Брейкин ньюс от экспертного отдела.
Подробности будут?
> Подробности будут?Будут, когда я опубликую статью о korgwm.
Если кратко: он сложнее для небольших проектов -- требует написать ещё композитор, у него хуже документация и в нём криво работает webrtc screen sharing -- как минимум, в дефолтном дебиане с гномом. Кто-то мне говорил, что после недели танцев с бубнами смог завести, но это too much. А ещё я не знаю, как они этого добились, но когда в одном и том же хроме пытаешься в конфлюенсе двигать страницы по иерархии, в вяленом даже не видно, куда страница встанет, там что-то не так с рендерингом этого плавающего окошка -- в иксах всё отлично.
Для всех этих недостатков нет ни одного достоинства, которое реально было бы в его пользу.
Пресловутый скейлинг и всё, что связано с этим лично я на глаз не различаю с иксами. Изоляция приложений на десктопе вообще никому не нужна. Какие там ещё киллерфичи...
> он сложнее для небольших проектов -- требует написать ещё композиторЗачем нужен в клиенте Wayland композитор?
> у него хуже документация
Хуже чего? Вот этого?
The window hierarchy
TODO
Last edited Sat 29 Mar 2014 03:59:04 PM UTC
По ощущениям автор говорил о написании в целом, для дистра, а не для клиента... не?
"Для дистра" ничего не пишут, а берут готовое, собирают и упаковывают в пакетики.
>> он сложнее для небольших проектов -- требует написать ещё композитор
> Зачем нужен в клиенте Wayland композитор?Затем, что это не простой клиент, а оконный менеджер.
> https://xcb.freedesktop.org/tutorial/
У xcb да, тоже смешная дока, но там комменты в коде есть и у меня почему-то не возникло проблем написать вм на xcb.
С вяленым труднее -- попробуй сам.
Или хотя бы почитай чужие исходники.
> С вяленым труднее -- попробуй сам.Как раз я и попробовал.
> Или хотя бы почитай чужие исходники.
Не нашёл в твоём профиле ссылки на твои исходники.
>> С вяленым труднее -- попробуй сам.
> Как раз я и попробовал.Скинь ссылку на твой вм, я тоже почитаю.
>> Или хотя бы почитай чужие исходники.
> Не нашёл в твоём профиле ссылки на твои исходники.https://github.com/zhmylove/korgwm
А вот интерфейс к xcb, тоже моего авторства:
https://github.com/zhmylove/X11-XCB
Его Миша держал, автор i3, но там ничего не было и мы с ним договорились, что я забираю, чтобы добавить вм-специфичную функциональность
>>> С вяленым труднее -- попробуй сам.
>> Как раз я и попробовал.
> Скинь ссылку на твой вм, я тоже почитаю.Кажется, я понял. Априори постулируется, что каждый пишет "ВМ", и на этом основании строятся некие выводы.
На практике подавляющее большинство пишет "приложения", то есть клиентов. При этом клиентов xcb надо ещё поискать (навскидку: Qt, mpv и, поскольку не вспоминается еще что-то, мой https://opennet.ru/53778-game). Остальные используют прослойки типа Qt или QTK+ (до сих пор обёртка надо Xlib).
>>> Или хотя бы почитай чужие исходники.
>> Не нашёл в твоём профиле ссылки на твои исходники.
> https://github.com/zhmylove/korgwmСпасибо, очень здорово видеть, что Perl жив и на нём пишут такие крутые штуки, как WM. Однако, если говорить о сложности, то для одной только инициализации Vulkan до состояния "чёрный квадрат" надобно 1000 строк на Си. С OLG последних версий не существенно меньше, как уверяют знатоки.
Если автору для себя не требуются все эти красивости, это одно. Если же говорить о графической оболочке, соответствующую запросам публики - то оказывается, что при отсутствии полноценной поддержки современного оборудования сравнивается незначительная часть кода.
> Кажется, я понял. Априори постулируется, что каждый пишет "ВМ", и на этом основании строятся некие выводы.Не, ты кажется не понял. Вот смотри:
* Новость про оконный менеджер.
* Ветка начинается с поста "Представлен новый оконный менеджер, и .. сразу на Иксах. Вэйланда нет."
* zhmylove написал в про сложность написания оконного менеджера для Вейленда, по сравнению с Иксами.И тут ты такой приходишь и делаешь вид, что речь идёт про GUI-приложения, а не про оконные менеджеры. Да ещё и передёргиваешь, что априори что-то там постулируется.
Ну да, сначала я не понял, потому что оконный менеджер для Wayland - это нонсенс (в смысле "не имеет смысла", а не как почему-то принято понимать). А потом понял, о чём и сообщил. И я надеюсь, автор уточнит в статье, что речь именно об оконных менеджерах, т.е. случаях редких, иначе эксперты начитаются и будут обобщать на всё.
> А вот интерфейс к xcb, тоже моего авторства:
> https://github.com/zhmylove/X11-XCB
> Его Миша держал, автор i3, но там ничего не было и мы
> с ним договорились, что я забираю, чтобы добавить вм-специфичную функциональностьПо этому поводу изначально у меня возник вопрос, почему именно XCB, а Xlib. XCB создавали, что бы уйти от блокирующих вызовов. То есть что бы гипотетически возможно было создать некий КА, который бы в цикле отправлял пачкой запросы, а на следующей итерации обрабатывал ответы, если они есть. Но живых вариантов такого я не нашёл. Xlib проще, потому её и используют поныне.
Глянул исходники, например вот это по сути дублирование кода из существующей реализации Xlib:
sub _screens_from_root {
my $self = shift;
my $cookie = $self->get_geometry($self->get_root_window());
my $geom = $self->get_geometry_reply($cookie->{sequence});
return [ X11::XCB::Screen->new(rect => X11::XCB::Rect->new($geom)) ];
}
т.е. наружу (для клиентов библиотеки) выставлена своеобразная реализация Xlib на Perl.
> т.е. наружу (для клиентов библиотеки) выставлена своеобразная реализация Xlib на Perl.Синхронность это не единственный недостаток Xlib. Самая большая проблема -- кеши, непредсказуемость и сложность взаимодействия с X11.
XCB это не "асинхронный Xlib" -- это биндинги к Х протоколу, что расширяет возможности программы.
Например, некоторых вещей не было в Xlib (не было и в XCB), но удобнее было припилить их к XCB. Это как сравнивать Gtk2 и Gtk3, который уже на GObject Introspection сделан.Да, некоторые интерфейсы X11-XCB синхронные (для удобства), но "наружу" всё же выставлена нормальная реализация xcb. Там не всё в исходниках видно, бо́льшая часть всего генерируется при сборке.
Вот когда нужна предсказуемость, в частности более-менее гарантированное время отклика на действие пользователя ("тиринг" лишь частный случай, есть ещё "инпут лаг"), тогда оказывается, что реализовать самому "композитор" - это необходимость, а не дополнительная сложность.
А основная претензия к Wayland, насколько я понял -- это монолит из сервера и менеджера окон. То есть годным "композитор" был бы, предоставляй он возможность описать механизм управления окнами на удобном языке. В существующих реализация такое сделать возможно, но для этого потребуется перепилить их исходники. Догадываюсь, почему авторы не заморачиваются модульной архитектурой -- каждый полагает, что его управление окнами самое лучшее.
>>> он сложнее для небольших проектов -- требует написать ещё композитор
>> Зачем нужен в клиенте Wayland композитор?
> Затем, что это не простой клиент, а оконный менеджер.Wayland это протокол. Есть серверная часть (т.н. "композитор"), есть клиентская. Небольшой проект - это клиент.
>>>> он сложнее для небольших проектов -- требует написать ещё композитор
>>> Зачем нужен в клиенте Wayland композитор?
>> Затем, что это не простой клиент, а оконный менеджер.
> Wayland это протокол. Есть серверная часть (т.н. "композитор"), есть клиентская. Небольшой
> проект - это клиент.Всё ещё не вижу ссылки на исходники твоего оконного менеджера, а не окошка с хелловолдом ;)
>>>>> он сложнее для небольших проектов -- требует написать ещё композитор
>>>> Зачем нужен в клиенте Wayland композитор?
>>> Затем, что это не простой клиент, а оконный менеджер.
>> Wayland это протокол. Есть серверная часть (т.н. "композитор"), есть клиентская. Небольшой
>> проект - это клиент.
> Всё ещё не вижу ссылки на исходники твоего оконного менеджера, а не
> окошка с хелловолдом ;)Видишь ли, меня Perl (а точнее, его ВМ, то есть вирт.машина) для таких целей не устраивает (не смотря на то, что против языка ничего не имею). Пришлось делать свой интерпретатор, он рядом тем с хелловолдом. Всё еще есть желание говорить о сложности "ВМ", сравнивая лишь Wayland и xcb?
Ну раз Perl тебя не устраивает, где ссылка на твой Window Manager на другом языке, не на Perl?
Я понимаю, что галантерейщик и кардинал это сила, но мне больше пользы будет пообщаться с кардиналом.Если тебе действительно интересно, то такой есть рядом с хелловордом, на асме Z80. Окошек там не много, но в отличие от всего нынешнего, обеспечен "жёсткий реалтайм".
> Видишь ли, меня Perl (а точнее, его ВМ, то есть вирт.машина) для
> таких целей не устраивает (не смотря на то, что против языка
> ничего не имею).Just for your information: у Перла нет виртуальной машины
>> Видишь ли, меня Perl (а точнее, его ВМ, то есть вирт.машина) для
>> таких целей не устраивает (не смотря на то, что против языка
>> ничего не имею).
> Just for your information: у Перла нет виртуальной машиныThe work of the interpreter has two main stages: compiling the code into the internal representation, or bytecode, and then executing it.
https://github.com/Perl/perl5/blob/5459eb2e968db0aa506200323...
Виртуальная машина - это исполнитель байт-кода. Так называется, поскольку реализует виртуальный процессор, для которого байт-код является машинными инструкциями.
И даже если на деле вместо этого JIT компиляция, это не существенно. Меня не устраивает сборка мусора в неподходящий момент.
> И даже если на деле вместо этого JIT компиляция, это не существенно.
> Меня не устраивает сборка мусора в неподходящий момент.Это не jit, там нет никакой виртуальной машине и тем более сборщика мусора. А слово bytecode, я подозреваю, там появилось ещё до того, как придумали java.
И оно тут в другом значении.
> А слово bytecode, я подозреваю, там появилось ещё до того,
> как придумали java.Байт-код вообще появился задолго до того, как придумали Java. Н.Вирт называл такое P-code.
Вот опкоды Perl:
typedef enum opcode {
OP_NULL = 0,
OP_STUB = 1,
...
OP_METHSTART = 419,
OP_INITFIELD = 420,
OP_CLASSNAME = 421,
OP_max
} opcode;https://github.com/Perl/perl5/blob/48d382667948f6a16c732c477...
Размером больше байта, что сути не меняет, поскольку его размер и в Си стандартизировали относительно недавно.
> там нет никакой виртуальной машине
Here's an older description from Larry.
Perl's compiler is essentially a 3-pass compiler with interleaved phases:
A bottom-up pass
A top-down pass
An execution-order passЕсть терминологическая неоднозначность. Если Perl не переводит исходный текст в инструкции целевой машины, значит это не компилятор (для такой машины). Но компилятор там есть - в вышеупомянутый коды операций (и было бы странно, если бы он всякий раз при исполнении раз разбирал текст). Эти кода исполняет машина, не реализованная в железе, а потому она - виртуальная.
/* This file contains the main Perl opcode execution loop. It just
* calls the pp_foo() function associated with each op, and expects that
* function to return a pointer to the next op to be executed, or null if
* it's the end of the sub or program or whatever.
...
*/...
/*
* 'Away now, Shadowfax! Run, greatheart, run as you have never run before!
* Now we are come to the lands where you were foaled, and every stone you
* know. Run now! Hope is in speed!' --Gandalf
*
* [p.600 of _The Lord of the Rings_, III/xi: "The Palantír"]
*/int
Perl_runops_standard(pTHX)
{
OP *op = PL_op;
PERL_DTRACE_PROBE_OP(op);
while ((PL_op = op = op->op_ppaddr(aTHX))) {
PERL_DTRACE_PROBE_OP(op);
}
PERL_ASYNC_CHECK();TAINT_NOT;
return 0;
}https://github.com/Perl/perl5/blob/48d382667948f6a16c732c477...
> и тем более сборщика мусора.
В мои планы не входило в ходе дискуссии скачивать сорцы Perl и что-то там искать, полагаю, что цитат выше достаточно для начала. Устройство интерпретаторов в общем виде я знаю, как и несколько частных случаев. Если в языке нет явного управления памятью, значит это делает за программиста "рантайм". Консервативный сборщик, уплотняющий ли, или же там подсчёт ссылок - это дело десятое. Под мои требования к "ВМ" не очень подходит даже free(), поскольку там нет гарантии O(1).
Мне дальше лень.
Спасибо, понял. Считал перловиков некоей особой кастой, этакими хранителями традиций. В том числе и способными ткнуть носом в код.
Хочу немногл пояснить для себя иксы и разобраться в сраче между поклонниками X и Wayland. Одни говорят что иксы протухли другие, что концепция у них хорошая, но все испортили библиотеки-костыли
99% экспертов ничего не писали ни под xcb, ни под Wayland.
Гипотетически можно же в иксах внедрить изоляцию приложений?
> Гипотетически можно же в иксах внедрить изоляцию приложений?Конечно можно :) Через всякие Xnest
Ну теперь это надо написать на Elixir.
> Ну теперь это надо написать на Elixir.Тю. Это слишком банально. Ты вот на баше оконный менеджер попробуй напиши! А если покажется мало то неплохо бы и на брейнфаке.
На Баше или лучше на posix shell было бы очень хорошо.
Фи, на Perl уже давно есть [korgwm]
На коммон-лишп
Тоже есть, и тоже давно. И на elisp тоже есть. На лиспах такие вещи (да и все остальные, в общем-то тоже) писать сплошное удовольствие. Но для этого надо видеть дальше скобочек, а на этом 99.9999999999% диванных сливается.
На хаскеле поинтересней с точки зрения строгости, сайд эффектов и чистоты. На Лиспе скучно)
А мне не надо интереснее. Мне надо чтобы написал, и работало потом 20 лет без переписывания.
Как xmonad?
> Как xmonad?github/xmonad/xmonad-contrib/blob/master/CHANGES.md
"Dropped support for GHC 8.4."
Красава. Модно, молодежно. Лови момент.
Отрицай, лиспер : )
На закрывающие скобочки лисперы мало смотрят, в основном ориентируются на отступы (как бы это странно не звучало), есть даже srfi для схемы в виде языка с отступами https://srfi.schemers.org/srfi-119/srfi-119.htmlКстати, в той же схеме и других диалектах можно смешивать круглые и квадратные скобки для читабельности, например, можно посмотреть в код chezscheme и увидеть как это выглядит.
Ну и давно есть различные плагины для балансирования скобок в редакторах.
Вот именно это я и имел в виду, когда говорил про видеть дальше скобочек. Дело не в редакторе и не в отступах. Дело в гомоиконности. Но диванным нужен плагин.
Нееее... Первое, что нужно "диванным"(ТМ) - это чтоб платили. За lisp вот практически не платят. Одно время вроде за closure вполне себе - но лет уже не мало как по ощущениям все "наигрались", не в последнюю очередь по причине очень уж унылого перформанса.
дык есть и просто PerlWM
Последний релиз PerlWM датирован 2004м годом.
Он, конечно, есть, но он неюзабелен: по функциональности он даже хуже TWM.
Ну и сыпет варнингами и TODO при работе.Короче, PerlWM -- это PoC, а не рабочий инструмент.
Глянул на гитхабе. Ты молодец. Не думал что встречу перлхакера на опеннете.Можно вопрос? А yaml конфигурация принципиальна? Обрезает же возможности расширения.
Вместо простыни из
<code>
mod_ctrl_1: 'tag_append(1)'
mod_ctrl_2: 'tag_append(2)'
mod_ctrl_3: 'tag_append(3)'
mod_ctrl_4: 'tag_append(4)'
mod_ctrl_5: 'tag_append(5)'
mod_ctrl_6: 'tag_append(6)'
mod_ctrl_7: 'tag_append(7)'
mod_ctrl_8: 'tag_append(8)'
mod_ctrl_9: 'tag_append(9)'
mod_shift_1: 'win_move_tag(1)'
mod_shift_2: 'win_move_tag(2)'
mod_shift_3: 'win_move_tag(3)'
mod_shift_4: 'win_move_tag(4)'
mod_shift_5: 'win_move_tag(5)'
mod_shift_6: 'win_move_tag(6)'
mod_shift_7: 'win_move_tag(7)'
mod_shift_8: 'win_move_tag(8)'
mod_shift_9: 'win_move_tag(9)'
</code>написал бы:
<code>
for my $i (1..9) {
definekey "mod_ctrl_$i" tag_append($i)
definekey "mod_shift_$i" win_move_tag($i)
</code>
не говоря уже о возможности определять свои функции в конфиге, наследовать поведение и расширять базовые возможности on-the-fly, что-то типа emacs/vim'a.
Это да, в lib/X11/korgwm/Config.pm так и написано.
Например: "(map {; "mod_ctrl_$_" => "tag_append($_)" } 1..9),"Почему не сделал "do $config_file"?
Не было необходимости, но это всегда легко дописать :)Почему взял YAML? Никакой религии за этим нет. Взял потому, что это простой способ читать структурированные файлы. Предварительно поговорил с ребятами из Modern::Perl, кто чем сейчас пользуется.
Лично я обычно, как ты и предлагаешь, как раз конфиги пишу в perl коде и потом просто исполняю их.
Здесь мне хотелось чего-то, что смогут править не знающие perl люди.Как-то так :)
P.S. я планирую как-нибудь написать статейку о korgwm, как и зачем я его писал. Просто пока времени нет. Но использую я его каждый день, это не PoC, а мой рабочий инструмент :)
>[оверквотинг удален]
> Почему взял YAML? Никакой религии за этим нет. Взял потому, что это
> простой способ читать структурированные файлы. Предварительно поговорил с ребятами из
> Modern::Perl, кто чем сейчас пользуется.
> Лично я обычно, как ты и предлагаешь, как раз конфиги пишу в
> perl коде и потом просто исполняю их.
> Здесь мне хотелось чего-то, что смогут править не знающие perl люди.
> Как-то так :)
> P.S. я планирую как-нибудь написать статейку о korgwm, как и зачем я
> его писал. Просто пока времени нет. Но использую я его каждый
> день, это не PoC, а мой рабочий инструмент :)Ну, большой разницы для незнающих Perl между "key: val" и "$key = 'val'" особо нет. Тем более, что ты сам тестируешь перл код, только тратишь время еще и на вынос этих переменных в yaml. А для новичков всегда можно в конфиге explicitly написать, без map'a, от А до Я, тогда разницы вообще никакой. Зато, если в "Apply Rules" если мне захотелось бы сделать матчинг не только по WM_CLASS, но и по WM_NAME, или по WM_ROLE, то при соответствующей организации кода я бы получил возможность:
$config->{rules} = {
{ class => "Sylpheed", title => "sylpheed", role => "Input Password" } =>
{ screen => 2, tag => 2, follow => 0, urgent => 1, },{ class => "Sylpheed", title => "sylpheed", } =>
{ screen => 2, tag => 2, follow => 0, },
};Тобишь, просто добавить пару ключей, и переписать обработчик. Разумеется при должной организации кода, на что требуются дополнительные усилия с твоей стороны. А если охота сохранить возможность выноса этих переменных в yaml - то и еще дополнительных усилий. На что я само-собой не имею права, и прошу не воспринимать как указания. Кто я вообще такой... Ты сделал классную штуку, это достойно уважения и похвалы, снимаю шляпу. От меня звезда и подписка на RSS коммитов в гитхабе.
P.S. Но просто знай, если вдруг, еееееесли, вдруг... не смею надеяться, но ееееесли... задумаешь повторить возможности хакинга stumpwm только на Perl'e, как перловщик и изредка непредумышленный коммитер в Perl, я опакечу korgwm в свой дистр, и буду контрибьютером. Ты забацал нереально классную штуку)
Круть, спасибо!А что у тебя за дистр?
BTW для ArchLinux и FreeBSD я уже сделал пакет в AUR и порт, соответственно.
Опеннет вроде режет ссылки, потому напишу так: github/zeppe-linВдохновлялся NetBSD и CRUX. ^_^
Спасибо. Посмотрел на гитхабе -- отличный проект. Так что снимаю шляпу и ставлю звезду взаимно :)
Ну, после столь нетипичных для опеннета любезностей, мы просто обязаны жениться. :-D
Шучу, спасибо бро. Удачи с проектом, и как говорится, have fun.
Now kiss.
> для ArchLinux и FreeBSD я уже сделал пакетАх ты мой хороший!
Не, на скриншотах фигня какая-то сопливая, не катит, тема оформления недостаточно нapкoмаaнcкaя!
К такой душной прозрачности не хватает ещё повсеместных кислотных цветов в теме оформления, вот тогда - збс будет!
Любитель серой плоскоты?
> Любитель серой плоскоты?Любитель навешивать ярлыки и рассовывать всё по коробочкам? ;)
>Ryby
>X11Очень свежо и актуально
Помню на руби делали текстовый редактор, аналог textmate (тогда его код ещё был закрыт) и назывался он redcar https://github.com/danlucraft/redcarПомню как ради интереса попробовал его: тормоз был просто жуть.
1. Найти какой-нибудь забытый Богом проект.
2. Сделать о нём вывод обо всём языке программирования.
3. PROFIT!?Попробовать какой-нибудь нормальный софт на том же языке, тот же AsciiDoctor? Не, зачем?
> 1. Найти какой-нибудь забытый Богом проект.
> 2. Сделать о нём вывод обо всём языке программирования.
> 3. PROFIT!?Сделать выводы по софту. Что не так?
> Попробовать какой-нибудь нормальный софт на том же языке, тот же AsciiDoctor? Не,
> зачем?AsciiDoctor - тулза и проект совсем другого уровня.
Если можешь написать работающую программу на рубях, значит можешь и быстренько выучить какой-нибудь язык, обеспечивающий приемлемую производительность. Казалось бы.
На С напиши, очень быстрая программа будет. Будет аж за 1 микросекунду окошко рисовать, против 3 на Руби. Ты же не тормоз, ты заметишь! А потом на Раст перепиши. Ну, подумаешь, в 10 раз дольше писать придётся. Зато окошко на 2 микросекунды быстрее рисоваться будет.
Нет смысла. Иксы являются узким местом. Мой хелловорд https://opennet.ru/53778-game позволяет это увидеть - запускаете варианты Wayland и XCB, хватаете окно мышкой за угол и начинаете быстро менять размеры туда-сюда. На Иксах стабильно пропускает по 1-2 кадра.