Есть несколько пожеланий по содержимому левого меню главной страницы..

1. Облако Меток

Жирное слово "программирование" сильно распирает левое меню, и делает его шире чем было. Я попытался побороться с этим установив "Число меток в облаке", равное 0, все равно я ими не пользуюсь. Но однако оказалось что этого нельзя, и теперь в метках у меня красуется гордоя одна метка, как и раньше распирающся меню вширь... Очень бы хотелось, бы чтобы было можно сделать так чтобы, либо чтобы "программирование" не распирало меню, или чтобы чтобы его можно было просто убрать облако как класс (либо разрешить число меток = 0, либо добавив галочку, отключающее облако)

2. Top 10

Числа от 2 до 45 подряд там кажутся слегка неуместными... Достаточно было бы "2, 3 ... 44, 45" кому надо именно 43ию страницу могут и два клика сделать... (Но это мысли вслух, раз уж все равно пишу... оно мне не особо мешает)

>>>

Поймал себя на том, что время от времени мне оказываются полезными, или как минимум интересными, сообщения о минорных релизах, из неподтвержденных новостей. Есть подозрение, что я не один такой.

То что такие сообщения не попадают на главную страницу -- в общем правильно... Нечего им там делать. А вот то что они вместо этого попадают в удаленные -- неправильно. И даже если будут попадать во всякие толксы, то тоже будет неправильно... Ибо выуживать их там из прочего трафика, мягко говоря неудобно.

На мой взгляд была бы крайне полезна отдельная премодерируемая лента новостей/раздел форума, в которую бы попадали оные сообщения о минорных релизах... Че зря информацию в удаленные выкидывать....

Вот... Сорри если не в тему... накопилось ;-)

>>>

Выполню разовые заказы в области perl-программирования. Возможно долгосрочное сотрудничество.

Могу изредка появляться офисе (Москва)

http://shaplov.ru/resume.html

Есть ноутбук... 
Миди устройств, как я понял в нем нету.
Хочу издать из колонок ноту ми, чтобы настроить гитару.
Как можно оного эффекта добиться?

sim-im теряет конфиг, если на диске кончилось место... Старый стирается, новый оказывается пустой (места то нет).

Полез внутрь...
Там примерно следующее:

  QFile f(cfgName + BACKUP_SUFFIX); // use backup file for this ...
    if (!f.open(IO_WriteOnly | IO_Truncate)){
        log(L_ERROR, "Can't create %s", (const char*)f.name().local8Bit());
        return;
    }
    for (unsigned i = 0; i < plugins.size(); i++){
      QCString line = "[";
      // Тут дальше формируется строка 

      f.writeBlock(line, line.length());

     // Ну еще кое-что таким же способом пишется... 

    }
    const int status = f.status();
    const QString errorMessage = f.errorString();
    f.close();
    if (status != IO_Ok) {
        log(L_ERROR, "I/O error during writing to file %s : %s", (const char*)f.name().local8Bit(), (const char*)errorMessage
        return;
    }

Не смотря на то, что директорию с конфигом я засимлинкил на заведомо переполненный раздел, оно почему-то продолжает прибывать в уверенности, что все записалось как следует. И на этом основании уничтожает старый конфиг.

Заменил f.writeBlock(line, line.length()); на

 int size1= f.writeBlock(line, line.length());
        if ( size1 != (int) line.length() ){
           log(L_ERROR, "Error writing file: %s but continue writing...", (const char*)f.name().local8Bit());
           // return;
        } else
        {
          log(L_ERROR, "%i of %i bytes successfuly written in file: %s",size1 , line.length(),(const char*)f.name().local8Bit
        }

Итог: writeBlock свято уверен, что у него все получается...

Попробовал воспроизвести ситуацию в отдельной программе. В отдельной программе: все работает. Как только место заканчивается writeBlock начинает возвращать 0, как ему и положено. Мало того, с другим конфигом, который пишется в симе (их там более одного) все проходит нормально, статус возвращается правильный, и когда место кончилось старый конфиг не стирается.

Кто нибудь с таким сталкивался. Может посоветуете, что делать/ где чего подкрутить/ что читать/ где спросить?

Полный текст функции можно посмотреть тут:
http://svn.berlios.de/viewcvs/sim-im/trunk/sim/plugins.cpp?view=markup

Поскольку в топике про Parrot остались только питоно(фило/фобы), повторю свой вопрос здесь, ибо хочу услышать ответ...

================================

> Имхо, сила перла во всяких фишках и пр. мелочах. Ну и конешно CPAN...

А вот скажите мне, умные люди... Я вот уже несколько лет наблюдаю в поцесе работы оный CPAN и создается у меня такое впечатление, что там ничего не происходит... Последние обновления нужных мне модулей -- трех-четырех летней давности... В ReportBugs висят баги и патчи, а новых версий не появляется... А например в RTF::Parser почему-то куда-то протаптались предидущие версии, а текущая вдруг почему-то помечена как ** UNAUTHORIZED RELEASE **

Чем и как вообще живет нынче CPAN и каковы процессы в нем происходящие? Всегда ли там все так было шаляй-валяй, или новомодное веянье?

=================================

Надоело мне что в audacious вместо русских букв вопросительные знаки, и я полез разбираться...

Докопался до glib'овскомо gconvert.c в котором есть функция g_filename_to_utf8 которая в свою очередь дергает функцию get_filename_charset

И вот что удивительно, в случае если не установлены переменные окружения G_FILENAME_ENCODING и G_BROKEN_FILENAMES, то эта нехорошая функцияпочему-то решает, что раз так, то будем жить в уникоде...

В дебиане под KDE эти переменные out of box не установленны... А локаль стоит KOI8-r потому что я mc нежно люблю...

Итого, на не уникодных локалях в debian под KDE часть GTKшынх программ из коробки работает не верно...

Вообще, исходя из доступной мне логики, в случае если не сказано явно в какой кодировке файловая система, то по всей видимости логично использовать кодировку из текущей локали, а никак не уникод...

В связи с этим собственно говоря вопрос, какой логикой руководствовались разработчики GTK делая такую конструкцию, и пыталисть ли им объяснить, что так делать лучше не надо?

И какой логикой руководствовались майнтейнеры пакета libglib2.0-0 не позаботившись о том чтобы были правильно выставлены переменные окружения, или не наложив патч чтобы все эти переменные окружения не мешали нормальной работе... Пытались ли им объяснить что что-то из этого надо бы сделать?

Не посоветуете ли на чем лучше всего поднять IMAP сервер на локальной машине, чтобы почтовый архив хранить?

Требования: чтобы умел не светиться наружу, и в неактивном режиме минимально занимал память и процессор. Никакой безопасности и высокой производительности не надо...

Поверхностный поиск дал Binc IMAP, но я его боюсь... Там все год назад умерло, и ни слуху ни духу... Я боюсь начинать использовать софт который находится в таком статусе...

Что еще?