>>книги стараюсь покупать бумажные, поэтому всякие смотрелки не нужны

Квартира от складирования не треснет?)

Площадь квартиры растёт пропорционально числу прочитанных книг.

wmii прекрасно настраивается через его vfs

>лёгкого GTK+-меню, написанного на Python

одно другому противоречит

Очередной Пуск. Стандартное и так ОК.

>Стандартное и так ОК.

А, это для GTK, ну нехай будет.

А вы не могли бы более детально код посмотреть на предмет таких ляпов? Конечно стыдно что они есть, но это все досталось в наследство от adeskmenu и хотелось бы исправить это на начальной стадии проекта.

стянул с launchpad код, стал открывать, а оно хочет для запуска какие-то gnomeapplet. Честно говоря дальше даже смотреть не стал.

И чем же оно лучше? Куча каких-то плагинов, отдельный конфигуратор... Сомневаюсь что оно хотя-бы быстрее SnapFly...

Возможно я просто не проникся... не знаю...

сравнили *опу с пальцем… MintMenu это GNOME-only, здесь целевая аудитория другая

>тем что удовлетворяет спекам freedesktop по части реализации меню

что люди не придумают, чтобы не юзать что-нибудь простое и логичное, вроде debianmenu

>вроде debianmenu

Толпа гентушников и арчеводов смотрит на тебя с непониманием…

Попробую, но мне лениво… Лучше создай тему в Development, там скорее всего сразу набежит толпа критиков. Мне по крайней мере помогло.

не плохо смотрится

Ну вот... Напишет кто-то что-то... Скажет об этом, а его тут же обосрут...
Зачем?

Ну что ж, поехали!

Смотрим /svn/trunk/src/snapfly

Сразу в глаза бросается x-terminal-emulator — я такое только в дебианах видел, в моей генте его нет, уж лучше xterm какой-нибудь.

Проверка доступности конфига, строка 58. В Development была тема в которой человек тоже долго и усердно проверял доступность файла, но ему обьяснили, что лучше сразу читать и проверять код ошибки (там про C было), а в нашем случае ловить исключение. Не уверен в 100% правильности такого подхода, но мне он кажется логичным, тем более, что состояние файла сразу после проверки и перед чтением может измениться.

Линия 142. Как я уже сказал иконки лучше закинуть в /usr/share/icons/hicolor и для их установки вызывать gtk.window_set_default_icon_name для установки иконки приложения по умолчанию (та что отображается в заголовке оконного менеджера) и метод set_from_icon_name для gtk.StatusIcon.

Это ЛОР!

Тут всегда так.

>Толпа гентушников и арчеводов смотрит на тебя с непониманием…

Я сам не понимаяю, почему эту штуку до сих пор никуда не портировали)

>Зачем?

Чтобы ЧСВ не зашкаливало)

>Площадь квартиры растёт пропорционально числу прочитанных книг.

Да, где-то было про чудака который клеил хибару из газет, но сейчас и хорошего клея задёшево не купишь, да и неэкологично это.

Может потому, что уже существует http://standards.freedesktop.org/menu-spec/latest/?

без ь-гомерзкого XML все гораздо проще, и уже давно работает с собственными меню боксов

> Можно подумать, что у большинства оно уже не стоит

Какая разница что там у большинства, меньшинства...

> A анонимусы у нас прям питонофобы.

Это один анонимус, только пишет много раз. В «удалённых» ещё куча однообразных клонов этого сообщения про «лёгкий питон».

>> A анонимусы у нас прям питонофобы.

Это один анонимус, только пишет много раз. В «удалённых» ещё куча однообразных клонов этого сообщения про «лёгкий питон».

Врёшь. Как минимум тут постили два анонимуса - я и ещё кто-то.

> лёгкого

Python

/0

по мне эффективный Alt+F2 b автокоплит

тормозит этот автокомплит

а вообще, dwm рулит.

>реализован функционал OnlyShowIn — вы можете спрятать значки программ из KDE или GNOME

Дискриминация по тулкиту? no way!

Тебе еще не надоел этот тупой троллинг? Ознакомься уже со спеками! У разных DE могут быть их DE-специфичные утилиты, они и скрываются.

ну да..
но это несколько неприятно..

Весьма симпатично.

Где смотреть скриншоты?

По ссылке >>> Проект на гуглокоде

Легкое меню написанное на питоне - оксюморон.

>лёгкого

Python

Если сама задумка содержит логическую ошибку, то каков же код?!

Дык это же хорошо, если так.

Че докапались...

как всегда - как обсерать - так все мастера, как че нить полезного для общества сдалать - так все занятые, после работы усталые да и вообще время я МОЕ время лучше продам...

отменя - молодца пацаны! смотрится симпотно!

Тем более. Я не против Python, но считаю, что в данном случае C был бы более уместен, раз хотели сделать легковесное приложение.

Сыровато пока, желаю разработчикам удачи и сил!

> алгоритм вызова меню изменился с посыла сигнала SIGUSR1 на dbus-вызов, что позволило значительно _ускорить_ запуск меню

а вот отсюда поподробнее

>как всегда - как обсерать - так все мастера, как че нить полезного для общества сдалать - так все занятые, после работы усталые да и вообще время я МОЕ время лучше продам...

Не наезжай так необоснованно на всех - это раз.
И ребята молодцы, что пытаются что-то скреативить вместо того, чтобы просирать время в играх или с бутылкой пива. Но еслиб это что-то было ещё и полезно и грамотно продумано - былоб замечательно. Пока же это больше напоминает продукт популярных тут тем «а чтоб такого написать на питоне с караваном и плюшками и не длинее 500 строк». Это два.

Объясните, пожалуйста, что делает это меню? Что вообще делает эта программа?

Спасибо, пойду поковыряю ваш код...

> dwm + dmenu + surf + tabbed наше всё =)

surf

Имхо, не очень удобен (а вот surfraw - правда из другой оперы, очень даже), посмотрите в сторону luakit.

если бы тормозил то не пользовался бы

Спасибо всем за конструктивную критику. Есть еще много вещей, которые хочется доработать. И да, прошу не относиться очень строго, это мой первый опыт общения с питоном и gtk :) По ощущениям — понравилось.

PS. На моем нетбуке (Atom 1.6 GHz) работает вполне сносно, не тормозит.

dmenu

> Объясните, пожалуйста, что делает это меню? Что вообще делает эта программа?

Это автогенерящееся меню для вызова приложений, или вообще непонятно для чего абстрактное «меню» нужно?

> а вот отсюда поподробнее

SIGUSR1 был в adeskmenu, причем вызов был реализован как опция к основной проге. От этого само отображение меню тормозило (нажимаешь вызвать, а оно показывается через секунду-две). Так же такая конструкция нагружала проц на 100%. Как только перевели на dbus и выделили команду отображения в отдельный скрипт - прога перестала жрать проц и стала отображаться мгновенно (я разницы со стандартным меню опена не заметил)

> посмотрите в сторону luakit.

спс, посмотрим на этот vimbrowser )

Кстати, всем троллящим и интересующимся: проект возник спонтанно из желания NomerUNO получить нормальное динамическое меню в OpenBox, и моего желания посмотреть, что за зверь такой python :) В итоге все остались довольны, я получил кучу полезного опыта и удовольствия. Плюс в очередной раз немного помог OSS. Да, можно было бы написать на C с xlib, но это в данный момент не доставило бы мне столько фана и профита :)

>алгоритм вызова меню изменился с посыла сигнала SIGUSR1 на dbus-вызов, что позволило значительно ускорить запуск меню

Автор новости не путает понятия «алгоритм» и «механизм»?