вот очень интересно, почему в этом обществе так процветает инфатнтилизм? хоть предпосылки, предлагаемые техническим развитием, и есть, но они вроде как должны нивелироваться повышением криминогенной обстановки и болтаниями экономики, но тем не менее.
с каждым поколением количество мужчин, неспособных защитить свою семью или женщин, неспособных эту семью вести неуклонно понижается
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-а - все будет работать. но подобный вариант уж очень хаком пахнет, потому пока ищу другие решения
существует ли функция, обратная 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. второе пахнет грязным хаком, зато быстро реализуемо. первое - более правильно с архитектурной точки зрения, зато долго по времени. или может кто-то знает более другие обходы подобной ситуации?
что опять с gnomefiles.org случилось, кто-нибудь в курсе?
народ, а не могли бы вы тут кратенько (ну или конспективно) описать свои критерии «шг». а то иной раз непонятки возникают
у меня в огнелисе, как самосборном, так и в официальных сборках, проявляется дурацкая ситуация - если в textarea нажать insert - фаер сегфолтится. в обычных полях это не проявляется. у кого-нибудь еще такая ситуевина воспроизводится, или это карма у меня попорченная?
затачивая тему под маленькое разрешение нетбука обнаружил достаточно мерзкий артефакт - при уменьшении [xy]thickness вокруг некоторых некоторых виджетов, находящихся в фокусе, появляется очень мерзкая жирная рамка отвратительно синего цвета.
борьба с этим явлением привела к исходникам темы и обнаружению хорошей опции движка - disable_focus
в связи с чем и вопрос - может еще кто интересные недокументированные фичи обнаруживал?
проблема в следующем, gtk_file_chooser_set_do_overwrite_confirmation() работает только, если GtkFileChooser получен из GtkFileChooserDialog, если же создавать свой диалог, и встраивать в него GtkFileChooserWidget, использование gtk_file_chooser_set_do_overwrite_confirmation() не дает никакого эффекта
рабочий код
#include <gtk/gtk.h>
int
main (int argc, char *argv[])
{
GtkWidget *d;
gtk_init (&argc, &argv);
d = gtk_file_chooser_dialog_new ("Save File", NULL,
GTK_FILE_CHOOSER_ACTION_SAVE,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT, NULL);
gtk_file_chooser_set_do_overwrite_confirmation (GTK_FILE_CHOOSER (d), TRUE);
gtk_dialog_run (GTK_DIALOG (d));
gtk_widget_destroy (d);
}
нерабочий код
#include <gtk/gtk.h>
int
main (int argc, char *argv[])
{
GtkWidget *d, *w;
gtk_init (&argc, &argv);
d = gtk_dialog_new_with_buttons ("Save File", NULL,
GTK_DIALOG_MODAL |
GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT, NULL);
w = gtk_file_chooser_widget_new (GTK_FILE_CHOOSER_ACTION_SAVE);
gtk_file_chooser_set_do_overwrite_confirmation (GTK_FILE_CHOOSER (w), TRUE);
gtk_widget_show (w);
gtk_box_pack_start (GTK_BOX (gtk_dialog_get_content_area (GTK_DIALOG (d))),
w, TRUE, TRUE, 0);
gtk_dialog_run (GTK_DIALOG (d));
gtk_widget_destroy (d);
}
во втором случае пробовал добавлять обработчик сигнала confirm-overwrite, но без видимого эффекта, обработчик не вызывался
кто-нибудь знает, как заставить второй вариант вызывать диалог подтверждения перезаписи?
есть проект. код на c и bash. для сборки используются autotools. при добавлении поддержки gettext возникла следующая проблема - скрипты на bash не имеют расширения .sh, и поэтому игнорируются xgettext-ом.
в принципе, при использовании intltools, в POTFILES.in можно указывать свой тип для файлов, прописывая перед именем [gettext/<type>], однако gettext/shell пока не поддерживается, только всякие xml-форматы и конфиги. а при использовании gettextize тип для конкретного файла вообще невозможно указать (по крайней мере я не нашел такой возможности). Разве что через Makevars явно передавать xgettext-у аргумент --language, но тут тоже возникает бяка, так как языков несколько.
пока мне видится несколько вариантов решения этой проблемы:
- плюнуть на autotools и сделать систему сборки на голых Makefile-ах
- держать несколько GETTEXT_DOMAIN-ов, для каждого типа исходников свой
- (наиболее кардинальный) внести изменения в xgettext, чтобы эта скотина работала с mime-types, а не по расширениям или добавить gettext/shell в intltools
но все эти варианты достаточно костылеподобны. нет ли какого-то более элегантного решения?
есть ли подобные тулзинки? чтобы просто тушила экран через заданный промежуток времени, запрашивала пароль при активизации пользователя, и, самое главное, не была бы встроена в какой-то скринсейвер. ну и gtk-интерфейс - большой плюс.
такое в природе существует или самому писать?
есть виджет HtmlView, прицепленный к контейнеру GtkScrolledWindow
проблема в следующем - при открытии нового документа (измененние содержимого HtmlDocument) позиция вьюпорта остается прежней или откатывается до конца документа, если он меньше предыдущего.
вопрос - как прокрутить html виджет в начало? gtk_scrolled_window_set_vadjustment не помогает, т.к. изменяет только положение скролбара, но не виджет-потомок, использование html_view_scroll_to_node затруднено тем, что я не понимаю, как получить нужный DomNode, а доков - с гулькин хрен (вернее - вообще нет). если кто с подобным сталкивался - очень надеюсь на помощь.
версии софта:
libgtkhtml - 2.11.1
gtk+ - 2.18.3
периодически убиваются файлы /etc/gtk-2.0/gdk-pixbuf.loaders и /etc/gtk-2.0/gtk.immodules.
никто с подобным не сталкивался?
| ← назад | следующие → |