а что, фотки с православного (?) андроида уже не принимаются?
пытаюсь залить фото рабочего места, два дня подряд получаю сообщение о том, что у меня ничего не вышло, отчет разработчикам отправлен. фотка, вроде, правилам удовлетворяет, как по форме, так и по содержимому. доколе?
в меню «команды» последние три пункта не согласуются. «файл меню», «файл расширений» и дальше жуткое «редактировать файл расцветки имен». надо бы или просто «файл расцветки имен» или везде «редактирование» добавить.
и неплохо было бы туда же воткнуть редактирование кейбиндингов
когда mc запущен в screen субшелл по ctrl+o не отрисовывает содержимое, хотя по положению курсора видно, что что-то таки есть. такая же ситуация, если выбрать команду из истории (alt+h). команда добавляется в строку, но не отображается. отображение происходит только если попытаться редактировать, например нажав bkspace.
выхлоп mc --version
GNU Midnight Commander, версия 4.8.3
Скомпилирован с библиотекой GLib версии 2.28.8
С библиотекой ncurses
C поддержкой внутренней командной оболочки
С поддержкой фоновых операций
С поддержкой мыши в xterm
С поддержкой интернационализации
С поддержкой многих кодировок
Виртуальная файловая система: cpiofs, tarfs, sfs, extfs, ftpfs, fish, smbfs
Тип данных: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;
.screenrc
defshell -$SHELL
defscrollback 1024
# default TERM
term screen-256color
# xterm scrollbar
termcapinfo xterm* ti@:te@
# Look and feel
shelltitle "Shell"
#hardstatus alwayslastline
#hardstatus string '%{= kW}[%-Lw%{= Ck}%50>%n%f* %t%{-}%+Lw%<%{d} %=]%{d}[%{B}%c%{d}]'
caption always
caption string '%{= kW}[%-Lw%{= Ck}%50>%n%f* %t%{-}%+Lw%<%{d} %=]%{d}[%{B}%c%{d}]'
# Left Right ctrl key mods
bindkey "^[[1;5D" prev
bindkey "^[[1;5C" next
# Launchers
bind m screen -t " MC " env EDITOR=jmacs RUN_MC=1 mc -x -S implix256
bind r screen -t "Root" sudo su -l
bind t screen -t "Top " top
наблюдаю дурацкое поведение.
при подключении acer liquid e (на борту - android 2.2) для усб-накопителя появляется только устройство /dev/sdb. разделы карточки не видятся до первого обращения к устройству. т.е. достаточно сделать touch /dev/sdb - добавляется /dev/sdb1, срабатывает автомонтирование и прочие вкусности. udev версии 175.
написать соответствующее правило для удава - не проблема, вопрос в другом - это нормальное поведение или у меня одного не фарт такой?
Перемещено Dimez из Talks
вопрос - какие реально необходимые действия могут выполняться в скриптах пакетного менеджера перед инсталляцией или перед удалением пакета? для прединсталляционных приходит на ум разве что добавление пользователя, что вполне себе нахрен не нужно, и вполне может быть выполнено после установки пакета. а что еще?
нарвался сегодня на багу с memcpy. хорошо, когда есть исходники и любишь в свободную минуту полистать срачи. а то бы на одной из украинских аэс могла возникнуть очень нездоровая ситуация.
так что модераторы не всегда и правы, когда начинают модерировать без разбора направо и налево
обновил сегодня gtk до 2.24.8 на свою голову. через какое-то время с ужасом обнаружил, что в терминале напрочь отвалился Alt. расследование сего печального события привело к тупому фиксу в gtk
commit 32b70a56d13050b6d2b0a570c436da1c303814f3 Author: Michael Natterer <mitch@gimp.org> Date: Mon Nov 7 20:09:00 2011 +0100
gdk: exclude MOD1 from the virtual modifier mapping
which effectively nails down the MOD1 == ALT assumption that is valid in all other parts of GTK+. After the modifier abstraction fixes for OSX, the virtual mapping is now (correctly) used in more places, and caused problems with the common default PC keyboard layout on X11 that colocates ALT and META on the same key. (cherry picked from commit ac943bf69a87c992cfde59c6720ef08fdd20e683)
gdk/x11/gdkkeys-x11.c | 20 ++++++++++++-------- 1 files changed, 12 insertions(+), 8 deletions(-)
вот нахрена такое делать в стабильной ветке?
пришлось делать свой патчик, чтобы отменить это безобразие. если кому надо
--- gtk+-2.24.8/gdk/x11/gdkkeys-x11.c.orig 2011-11-10 19:38:03.000000000 +0200
+++ gtk+-2.24.8/gdk/x11/gdkkeys-x11.c 2011-11-11 14:14:05.940999734 +0200
@@ -1684,12 +1684,13 @@
keymap = GET_EFFECTIVE_KEYMAP (keymap);
keymap_x11 = GDK_KEYMAP_X11 (keymap);
- /* See comment in add_virtual_modifiers() */
- for (i = 4; i < 8; i++)
+ for (i = 3; i < 8; i++)
{
if ((1 << i) & *modifiers)
{
- if (keymap_x11->modmap[i] & GDK_SUPER_MASK)
+ if (keymap_x11->modmap[i] & GDK_MOD1_MASK)
+ *modifiers |= GDK_MOD1_MASK;
+ else if (keymap_x11->modmap[i] & GDK_SUPER_MASK)
*modifiers |= GDK_SUPER_MASK;
else if (keymap_x11->modmap[i] & GDK_HYPER_MASK)
*modifiers |= GDK_HYPER_MASK;
@@ -1728,16 +1729,12 @@
keymap = GET_EFFECTIVE_KEYMAP (keymap);
keymap_x11 = GDK_KEYMAP_X11 (keymap);
- /* This loop used to start at 3, which included MOD1 in the
- * virtual mapping. However, all of GTK+ treats MOD1 as a
- * synonym for Alt, and does not expect it to be mapped around,
- * therefore it's more sane to simply treat MOD1 like SHIFT and
- * CONTROL, which are not mappable either.
- */
- for (i = 4; i < 8; i++)
+ for (i = 3; i < 8; i++)
{
if ((1 << i) & *state)
{
+ if (keymap_x11->modmap[i] & GDK_MOD1_MASK)
+ *state |= GDK_MOD1_MASK;
if (keymap_x11->modmap[i] & GDK_SUPER_MASK)
*state |= GDK_SUPER_MASK;
if (keymap_x11->modmap[i] & GDK_HYPER_MASK)
@@ -1825,8 +1822,7 @@
{
if (*state & vmods[j])
{
- /* See comment in add_virtual_modifiers() */
- for (i = 4; i < 8; i++)
+ for (i = 3; i < 8; i++)
{
if (keymap_x11->modmap[i] & vmods[j])
{
чего-то не пашет. в mc.keymap было прописано
PanelSortOrderByName = alt-n
PanelSortOrderByExt=
PanelSortOrderBySize=
PanelSortOrderByMTime = alt-m
и до 4.8.0 смена сортировки по alt-n/alt-m прекрасно работала. в 4.8.0 - не фурычит. конфиг подкладывал как в $XDG_DATA_HOME/mc так и $XDG_CONFIG_HOME/mc. запуск mc -K /path/to/mc.keymap также не дал никакого результата
ситуация следующая - означенные комбинации отказываются работать. при следующих условиях - терминал, основанный на vte, TERM установлен в xterm или xterm-256color, mc собран с ncurses.
если TERM установить в xterm-color - данных клавиши работают, однако отваливаются home и end на numpad-е, что еще более неудобно.
обучение не дает никакого эффекта, shift+f5 упорно опознается как shift+f7, shift+f6 - как shift+f8.
в связи с выходом 4.8.0 решил таки разобраться в этой ситуации. как оказалось
- vte работает с termcap и ложил с прибором на terminfo.
- в terminfo-вской базе для xterm и xterm-256color прописаны коды для 60 функиональных клавиш, у xterm-color - только для 20. причем коды разные.
- в /usr/share/mc/mc.lib прописаны несколько esc-последовательностей для функциональных клавиш, и похоже, они более приоритетны при обучении, нежели посылаемые пользователем.
не знаю, кто в этой ситуации дурак - разработчики vte, разработчики mc, томас дикий или все вместе, но я просто плюнул на все, и создал свой описатель xterm для terminfo - http://pastebin.com/SvsJzUse
если у кого возникла подобная проблема - скопируйте описатель в xterm.ti и соберите командой tic xterm.ti. для меня этот путь проблему решил.
теоретически, можно очистить нафиг /usr/share/mc/mc.lib и провести полное переобучение mc клавиатурным комбинациям, но способ со своим terminfo лучше, т.к. не затрагивает системный софт
$subj работает нормально. но только до тех пор, пока по ctrl+o не откроешь сабшел. после этого он функционировать отказывается до тех пор, пока не перейдешь в какой-нибудь каталог при помощи обычного энтера.
господа, а можно причину удаления писать в той-же строке, что и тему, не делая разрыва строки? а то очень уж похабно выглядит этот двухстрочник
хотелось бы услышать мнение о $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
| ← назад | следующие → |
