Ну хоть когда-нибудь хоть какой-нибудь встроенный язык добавят? Или так и будут анонсировать window.[button name].unfocus.pixmap как последнее слово в конфигурабельности?
Гм ... Знаете, я пользуюсь fluxbox`ом уже около 2-4 месяцев ... мои выводы: 1. Встроенный язык был бы не плох, но прямой необходимости нет. Так как то что есть, вполне хватает .... сейчас там всего-лишь дорабатывают поддержку XFree86 4.3.0 2. В этой верии замеченны баги, ... a) не устанавливаются NLS ... т.е. просто не собирается и не инсталится. Такая-же глюка была в 0.9.0 версии ... ;(( в 0.9.1 ее исправили .. в 0.9.2 она снова появилась ... b) Добавленно много опций в стили (описание themes), которые не описанны в конфиге ... но при подключении стиля (темы) он ругается, и говорит что берет по default`у .. ругается много ....
anonymous (2003-05-13 15:16:20.505) не... не убедительно. Объясни на пальцах :) просто приведи пару примеров где язык программирования реально нужен и используется
> не... не убедительно. Объясни на пальцах :) просто приведи пару примеров где язык программирования реально нужен и используется
Я хочу, чтобы при последовательном нажатии клавиш M-x t m все окна, имеющие в заголовке строку *term*, сдвигались на пятый десктоп и располагались определенным образом (в зависимости от того, что еще у них в заголовке). Как мне добиться этого от нынешнего fluxbox?
когда делаеш повторяюшиеся, частые операции - язык действительно нужен, а чтобы один раз отконфигурировать оконный манагер и потом забыть - овчина выделки не стоит. Тут скорее подойдет простой и понятный гуй-конфигуратор.
А я вот жду когда же наконец можно будет классам окна свои воркспэйсы назначать (например давишь на линк в гэйме на первом десктопе, а феникс открывается на третьем). Есессно имея встроенный язык все эти фишки не придется встраивать в сам вм. Пойду на ирке с девелоперами пообщаюсь.
Я себе уже давно сделал (в 0.1.14) перехват события OnCreateWindow и по конфигурационному файлу всякие действия с окнами. вот мой ~/.fluxbox/autos
class psi RemoveTab
class psi Workspace 1
class kmail RemoveTab
class kmail Maximize 1
class kmail Workspace 3
class Evolution RemoveTab
class Evolution Maximize 1
class Evolution Minimize
name Mozilla RemoveTab
name Mozilla Maximize 1
name Mozilla Workspace 2
class xmms RemoveTab
class Gvim Maximize 1
class bibletime Workspace 5
class bibletime Move 0 0 1024 768
class bibletime RemoveTab
class bibletime Maximize 1
Смотрится соответственоо на class.class и class.name (по аналогии с настройкой xxkb). Расортировывает новые окна по воркспейсам, делает то, что я делал раньше руками. А в ~/.xinitrc просто запускается сразу и psi, и мазилка и мыло, и ева. Очень удобно. Так что язык уже давно есть - c++ называется :0)). Если интересно, могу выслать патч. Только имхо я все-таки идеологически неправильно это сделал - не хватает мне знаний в программировании, особенно вм. То ли надо блокировать события на время обработки уже существующих, то ли просто флукс не такой стабильный, но иногда (примерно раз в 1.5-2 мес) бывает, что все глючит именно в момент появления нового окна. То, что я напрограммировал, есстно, делалось только под себя, для распространеия вообще не готово, но если интересно, пишите - вышлю. Он саавсем маленький.
Ну вот таким макаром будем встраивать языки во всё подряд ...
Идея кнешно сама по себе неплоха, за исключением одного но -
в unix нету аналога COM - то есть получится что в двухстах утилит
со встроенными языками одни и те же вещи делаются по разному -
это кому то надо ? Да и централизация скрптовых наподобии windows scripting host тоже не повредит иначе получится что вместе с оконным менеджером мне надо ставить питона а чтоб работал файловый менеджер
мне надо поставить ruby , и это при том что в жизни я ни тем не другим
не пользуюсь ....
> Ну вот таким макаром будем встраивать языки во всё подряд ...
Почему во все? Речь шла исключительно о WM. Вы бы еще сказали, что в шелле никакой скриптовый язык не нужен.
> Идея кнешно сама по себе неплоха, за исключением одного но - в unix нету аналога COM - то есть получится что в двухстах утилит со встроенными языками одни и те же вещи делаются по разному - это кому то надо ?
А что в этом плохого? Здоровая конкуренция. Те проекты, создатели которых ошиблись с выбором скриптового языка (и не могут заменить его), просто сдохнут.
> Да и централизация скрптовых наподобии windows scripting host тоже не повредит иначе получится что вместе с оконным менеджером мне надо ставить питона а чтоб работал файловый менеджер мне надо поставить ruby , и это при том что в жизни я ни тем не другим не пользуюсь ....
Ето да. Заменить elisp на scheme, а внутренний язык vim на lua, исправлением одной строчки в конфиге было бы прикольно.