хотелось бы услышать мнение о $subj
касательно себя - идейный тулкитофоб, потому как lfs и программер. и мне значительно проще добавить необходимую мне функциональность к используемому софту, нежели искать нечто, добавляющее нужное, но при этом усложняющее систему и/или дублирующее уже имеющиеся функции
сбылась места идиота. наконец-то выдалось время, и сделал то, что собирался уже года два. динамические xdg меню для fvwm
описание - в рассылке fvwm.fvwm.org, или пишите сюда, кому чего неясно на языке программирования си.
как наиболее оптимально реализовать subj?
пока что сделал так
static gboolean
regex_search (GtkTreeModel *model, gint col, const gchar *key,
GtkTreeIter *iter, gpointer data)
{
static guint pos = 0;
…
if (key[pos])
{
…
pos = strlen (key);
}
…
}
так как key — значение GtkEntry, а вызов функции повешен на «changed», то, по-идее, подобный алгоритм будет срабатывать всегда. но, возможно, что некоторых подводных камней я не заметил, так что если кто что подскажет - буду признателен
дело было вечером, делать было нечего
добавил поддержку печати во viewnior. кому надо, пользуйтесь - https://bugs.launchpad.net/viewnior/+bug/816563
как сочетается отказ от всяческих гарантий (пункт 15 лицензии) и возможность коммерческого использования gpl-софта? у кого-нибудь есть опыт разрешения подобного конфликта?
народ, а вот кто-то держит в системе этих зверей? сиречь .la файлы для libtool?
я вот одного понять не могу - жалуются людишки, дескать «тупят окружающие», «удалите этот коммент, потому как автор меня собакой назвал» и все такое прочее. ну или «я белый и пушистый, а козел-модератор мне хер на пятаки порубал, и только один на разживку оставил, никуда писать не могу».
а не проще ли просто пролистывать пустые комменты и обращать внимание только на существенные детали? вроде как аргумент «память нонче дешевая» - давно уже актуален. за трафик или время платить не надо, базу подобный мусор тоже не очень засрет, модераторам работы поубавится, анонимы, опять-таки счастливы. так зачем самим себе сложности создавать? аргументы противников подобной идеи, лично мне, напоминают жалобы человека, нюхающего дерьмо, и при это жалующегося на неприятный запах.
пост можно считать за фичреквест.
мне вот интересно, а чем обусловлен твой выбор причины удаления моего комментария в теме http://www.linux.org.ru/view-message.jsp?msgid=6423096 ?
я бы еще понял, если бы было 4.2 или 4.3, но флуд, сиречь «регулярная отправка бессмысленных текстов»?
такой вот милый ответ шона коннери на предложение сняться в рекламе apple. для Ъ не будет, потому что jpg
http://i69.photobucket.com/albums/i71/verona22/sean-connery-letter-jobs.jpg
вот очень интересно, почему в этом обществе так процветает инфатнтилизм? хоть предпосылки, предлагаемые техническим развитием, и есть, но они вроде как должны нивелироваться повышением криминогенной обстановки и болтаниями экономики, но тем не менее.
с каждым поколением количество мужчин, неспособных защитить свою семью или женщин, неспособных эту семью вести неуклонно понижается
subj вышел. всем радоваться 24 часа
есть такой простенький код
#include <gtk/gtk.h>
int main ()
{
GtkWidget *m, *i;
gtk_init (0, NULL);
m = gtk_menu_new ();
i = gtk_menu_item_new_with_label ("test1");
gtk_widget_show (i);
gtk_menu_shell_append (GTK_MENU_SHELL (m), i);
g_signal_connect (i, "activate", gtk_main_quit, NULL);
i = gtk_menu_item_new_with_label ("test2");
gtk_widget_show (i);
gtk_menu_shell_append (GTK_MENU_SHELL (m), i);
g_signal_connect (i, "activate", gtk_main_quit, NULL);
i = gtk_menu_item_new_with_label ("test3");
gtk_widget_show (i);
gtk_menu_shell_append (GTK_MENU_SHELL (m), i);
g_signal_connect (i, "activate", gtk_main_quit, NULL);
gtk_menu_popup (GTK_MENU (m), NULL, NULL, NULL, NULL, 0,
gtk_get_current_event_time ());
gtk_main ();
return 0;
}
собираю, запускаю - все нормально, менюшка показывается. пытаюсь зацепить эту же програмулинку на комбинацию клавиш в fvwm - и по нулям, меню нет.
Mouse 2 R A Exec exec $[HOME]/a.out
причем, если запускать Exec из FvwmConsole или при помощи FvwmCommand - все нормально, все показывается. также не наблюдается проблем, если основное окно имеет тип GTK_WINDOW_TOPLVEL.
привязки к виджету и попытки подпихнуть рутовое окно в через gdk_window_set_group() или gdk_window_set_transient_for() не помогли.
подозреваю, что если слепить обычное окно без обрамления и прочих пейджеров/таскбаров и подпихнуть его менюхе в качестве parent-а - все будет работать. но подобный вариант уж очень хаком пахнет, потому пока ищу другие решения
Вышел первый стабильный релиз ветки 2.6.x оконного менеджера Fvwm.
Из нового, по сравнению с последним бета-релизом (2.5.31) — поддержка libpng 2.5.0.
Также традиционные исправления ошибок:
Также была окрыта новая нестабильная ветка 2.7.x
>>> Подробности
существует ли функция, обратная g_markup_escape_text()?
в glib-овском markup.c подобная функция исключительно static, а других не нашел, потому пока пришлось велосипедить, и изобретать свое
делаю интерфейс в glade. накидал формочку добавляю combobox, привязываю к нему модель с опередленными данными. все вроде здорово, но есть одна гадость - для того, чтобы данные отображались надо вручную в коде добавлять комбобоксу cellrenderer и привязывать его к нужному столбцу модели. glade этого сделать, увы, не позволяет.
отсюда вопрос - это ограничение glade или GtkBuilder-а? и если ограничение только в glade, в какой форме задавать cellrenderer-ы в файле описания интерфейса?
нужен монитор. 19-21 дм, формфактор 4:3, наличие встроенных колонок, желательно снизу, а не по бокам. последнее условие (по размещению, а не наличию) не критично.
а вообще, сильно напрягает отсутсвие какой-то единой базы существующего оборудования. чтобы можно было подобрать модель нужной тебе железки, с нужными характеристиками и прочим фаршем, и потом уже знать, что искать по лавкам. или такое где-то существует?
можно ли изменить subj, программно или же через gtkrc, не меняя исходников самого движка? похоже, что clearlooks плевать хотел и на gtk_widget_modify_bg(), и на баловство с gtk_rc_style и прочие извраты
code=python мило херит табуляцию, что делает код нечитаемым.
вопрос к perl-guru. можно ли упростить этот код?
#! /usr/bin/perl -w
use Getopt::Long;
my $format=q(%artist% - %title%);
my $player;
GetOptions('player=s' => \$player, 'format=s' => \$format);
exit(1) if (!defined($player));
my $cmd = qq(dbus-send --print-reply --type=method_call --dest=org.mpris.MediaPlayer2.$player /org/mpris/MediaPlayer2 org.freedesktop.DBus.Properties.Get string:'org.mpris.MediaPlayer2.Player' string:'Metadata' |);
my %tags;
open (DBUS, $cmd) or die "Can't run $cmd: $!\n";
while (<DBUS>) {
my $tag;
my $value;
chomp;
s/^\s*(.*)\s*$/$1/;
if (m/dict entry\(/) {
while (<DBUS>) {
chomp;
s/^\s*(.*)\s*$/$1/;
last if (m/\)$/);
if (m/^string.*\"mpris:/) {
last;
} elsif (m/^string.*\"xesam:(.*)\"$/) {
$tag = $1;
next;
} elsif (m/^variant.*string.*\"(.*)\"$/) {
$value = $1;
next;
} elsif (m/^variant.*array/) {
while (<DBUS>) {
chomp;
s/^\s*(.*)\s*$/$1/;
last if (m/\]$/);
if (m/^string.*\"(.*)\"$/) {
$value .= $1 . ", ";
next;
}
}
$value =~ s/\,\s*$//;
}
}
$tags{$tag} = $value if defined($value);
}
}
close (DBUS);
# print results
if (defined($tags{'artist'})) {
$format =~ s/\%artist\%/$tags{'artist'}/g;
} else {
$format =~ s/\%artist\%//g;
}
if (defined($tags{'title'})) {
$format =~ s/\%title\%/$tags{'title'}/g;
} else {
$format =~ s/\%title\%//g;
}
if (defined($tags{'album'})) {
$format =~ s/\%album\%/$tags{'album'}/g;
} else {
$format =~ s/\%album\%//g;
}
if (defined($tags{'genre'})) {
$format =~ s/\%genre\%/$tags{'genre'}/g;
} else {
$format =~ s/\%genre\%//g;
}
print $format, "\n";
vte по умолчанию киляет потомка при помощи SIGHUP. zsh --login, при получении SIGHUP, своих потомков нормально не убивает. mc тупит и жрет cpu, если теряет управляющий терминал.
в результате имеем - практически все терминалки, основанные на vte, в случае, если шэлом выступает zsh --login и в нем запущен mc, в случае закрытия окна оставляют mc крутиться. загрузка по user подпрыгивает до 50-60%.
вопрос мучает - что колупать, сам zsh или тупо в терминале отлавливать delete-event и килять потомка по SIGKILL. второе пахнет грязным хаком, зато быстро реализуемо. первое - более правильно с архитектурной точки зрения, зато долго по времени. или может кто-то знает более другие обходы подобной ситуации?
| ← назад | следующие → |