Собственно, проблема в седующем.

Трей создал. По кнопке закрытия [X] окна оно у меня в него отлично сворачивается, но также хотелось бы, чтобы оно сворачивалось по кнопке сворачивания [_] окна.

Повесил коллбэк на "window-state-event", но событие GDK_WINDOW_STATE_ICONIFIED генерируется не только тогда, когда пользователь сворачивает окно, но и когда переключается на другой рабочий стол. Если при этом не скрывать окно, то Gnome впоследствии снимает флаг GDK_WINDOW_STATE_ICONIFIED, когда пользователь возвращается на этот рабочий стол, но если окно скрыть (что мне как раз и надо), он перестает снимать данный флаг.

Таким образом, заставить свое приложение сворачиваться по [_] в трей у меня так и не получилось. Подскажите, пожалуйста, можно ли это как-нибудь реализовать? Или, может быть, кто-нибудь знает какое-нибудь приложение, которое так умеет делать - посмотрю в исходниках.

Добрый день.

У меня следующая ситуация:
Пишу программу, в которой собираюсь использовать несколько библиотек, которые выпускаются под следующими лицензиями: LGPL, GPL и BSD (BSD-C3). Соответственно встает вопрос: "Имею ли я на это право?". Под какой лицензией будет моя программа - мне все равно, но вот можно ли одновременно использовать GPL и BSD библиотеки, и есть ли при этом какие-то ограничения (к примеру, на статическую линковку)?

Добрый день.

Обновился до 9.04 и получил неработающие иксы. Nvidia GeForce 6500, драйвера - nvidia-glx-180.

При попытке запустить иксы они падают, при этом утягивая за собой консоль. :) (F1,F2... не помогают - черный экран)

Вот лог Xorg:

Backtrace:
0: /usr/bin/X11/X(xorg_backtrace+0x3b) [0x813518b]
1: /usr/bin/X11/X(xf86SigHandler+0x55) [0x80c7be5]
2: [0xb8031400]
3: /usr/bin/X11/X(ActivateDevice+0x4f) [0x808662f]
4: /usr/bin/X11/X(InitAndStartDevices+0x42) [0x8086732]
5: /usr/bin/X11/X(main+0x36f) [0x807229f]
6: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7bee775]
7: /usr/bin/X11/X [0x80717a1]
Saw signal 11.  Server aborting.

xorg.conf: http://narod.ru/disk/8043642000/xorg.conf.html

Очень надеюсь на вашу помощь. :)

У меня в программе есть окно настроек. При создании окна помимо остальных виджетов я размещаю в нем GtkFileChooserButton и задаю ему при помощи gtk_file_chooser_set_filename() директорию, прочитанную из конфига.

Проблема возникает тогда, когда по каким-то причинам данной директории уже не существует. В этом случае GtkFileChooserButton автоматически "поднимается" вверх по дереву каталогов, пока не найдет существующую директорию. Мне же хотелось бы, чтобы он этого не делал. Перерыл документацию - ответа не нашел. Может быть, вы чем поможете?

Встал вопрос выбора библиотеки для реализации RPC в моей программе.

Что бы хотелось:
* Биндинги к C++.
* Адекватная документация.
* Чтобы работала через обычный TCP и, желательно, чтобы, если требуется работать только на одном компьютере, использовала UNIX сокеты.

Буду рад любому совету или ссылке на какой-нибудь обзор.

Вообще, на первый вгляд, если использовать самые распространенные решения, то, вроде бы, выбор остается только за xml-rpc и DBus.

xml-rpc, как минимум, не нравится тем, что это XML, соответственно, если придется гонять большой объем данных или часто вызывать удаленные методы, то это может очень плохо сказаться на производительности.

DBus удручает своей документацией и тем, что, насколько я понял, нормально с ним можно работать только через системную шину (которую просто так не захватишь - необходимо предварительно прописать себе права в /etc/dbus-1/system.d/, что не есть гут). Работа через сессионную шину - вообще сплошной геморрой: оказывается, далеко не во всех дистрибутивах иксы создают эту саму сессионную шину + если пользователь сдуру запустит в терминале новую сессию, то ее никто не увидит, т. к. все остальные приложения будут находиться вдругой сессии. Про TCP в документации вообще ни слова кроме ссылки на man dbus-daemon.

Вообщем, надеюсь на вашу помощь.

P.S.: или, может быть, плюнуть на все это и вручную написать на сокетах? :)

Столкнулся со следующей проблемой:

Устанавливаю Tooltip на какой-нибудь виджет, пользователь наводит на данный виджет курсор, отображается тултип, и если я в этот момент обновлю какой-нибудь виджет окна, то тултип пропадает.

Причем пропадает Tooltip всегда. Даже тогда, когда обновляемый виджет никакого отношения не имеет к тому виджету, для которого отображается тултип (он может быть даже в другом окне).

Происходит это везде - если я даже назначу тултип для GtkStatusIcon, то при обновлении виджетов окна он пропадает.

Помогите, пожалуйста. Даже не знаю, куда и смотреть.

Добрый день.

Ткните, пожалуйста, ссылкой на какой-нибудь HowTo по реализации lock-файлов, или подскажите, в какую сторону копать.

Что конкретно нужно:
При запуске программа смотрит, существует ли lock-файл. Если да, то каким-либо образом соединяется с уже запущенной копией, передает ей параметры командной строки и завершает работу.
Если lock-файл не существует, то создает его и начинает работу.

Проблема, собственно, в атомарности: как разрешить ситуацию, когда запускается одновременно несколько экземпляров приложения (в итоге остаться работать должно только одно из них) + если приложение создает lock файл, и его потом убивают через kill -9, то файл останется в системе...

Вообщем, думаю, все эти проблемы уже давно решены. Подскажите, пожалуйста, где можно найти это самое решение.

На днях листал заголовочные файлы boost и наткнулся на следующие строки:

    template<class Path>
    class basic_filesystem_error : public filesystem_error
    {

      ...

      const path_type & path1() const
      {
        static const path_type empty_path;
        return m_imp_ptr.get() ? m_imp_ptr->m_path1 : empty_path ;
      }

      ...

    };

Не поделитесь мнениями или ссылками, как лучше и проще реализовать наследование в C? Пока что единственное, с чем встречался - это Glib, но как-то у них уж больно сложно, хотелось бы по-проще без лишнего гемороя. Может быть есть уже хорошо описанные подходы или библиотеки для реализации подобных вещей?

Добрый день. Вот задался таким вопросом. Думаю, какой вариант выбрать:
1. Все строки внутри приложения хранить и обрабатывать в Glib::ustring (в случае с gtkmm, или в каком-нибудь другом строковом классе с поддержкой юникода, когда приложение пишется не под GTK) и преобразовывать в кодировку локали только тогда, когда необходимо использовать строку как имя файла, записать в файл, вывести на консоль и т. п...
2. Все строки внутри приложения хранить в кодировке локали и преобразовывать в UTF только тогда, когда требуется, например, передать строку функциям gtkmm (опять же в случае, когда приложение пишется под GTK).

Первый вариант, вроде бы, предпочтительней, т. к. позволят приложению работать с символами, которых может не оказаться в кодировке текущей локали, но: далеко не все библиотеки поддерживают юникод, и, как правило, их функции принимают std::string. Если функция библиотеки принимает std::string, то она воспринимает ее как строку в кодировке локали, а не как UTF строку, следовательно, если она выполняет какие-то действия с данными строками, то, возможно, попытка обработать UTF строку вызовет у нее ошибку.

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

Вот возник такой вопрос. Интересует чисто теоретически - на практике применять не буду. =)

Допустим, есть один поток, который изменяет переменную, и есть один поток, который ее считывает. Насколько безопасно это делать без мьютексов?

Вроде бы, на 32-ух разрядных машинах int укладывается в один регистр, а значит, насколько я понимаю, его запись атомарна, но если использовать на той же машине, к примеру, int64_t, который умещается только в два регистра, то такая запись не атомарна, и есть вероятность что при считывании из другого потока мы считаем число, у которого одна половинка будет новая, а другая - старая.

Я правильно рассуждаю, или все не так просто?

P.S.: про volatile я знаю. Насколько я понимаю, он запрещает только "кешировать" значение int'а в регистре между несколькими обращениями к переменной и ничего больше. Причем, также насколько я знаю, при вызове функции компилятор "сбрасывает" подобные кэши, исходя из предположения, что данная функция может как-то изменить данную переменную (просто присвоив значение, если она глобальная или через указатель, если она локальная).

А тут я прав? =)

Моя программа кроме стандартных библиотек использует еще пару таких, которые присутствуют далеко не в каждом дистрибутиве. И вот я стою перед выбором: либо включить данные библиотеки в пакет с исходными текстами и избавать пользователей от необходимости бегать по интернету, скачивать и устанавливать эти библиотеки только ради моего приложения, либо сделать по UNIX-way и не включать их в пакет.

Что, посоветуете? Считается ли дурным тоном включение сторонних библиотек в пакет с исходными текстами с целью облегчения сборки, или это нормальное явление?

Доброго времени суток.

Вот надумал написать man для своей софтины. С английским man'ом все понятно, но вот в какой кодировке писать русский man? Ведь программа будет устанавливаться на дистрибутивы с различными локалями, и, насколько я понимаю, если в дистрибутиве, к примеру, используется локаль ru_RU.KOI8-R, то man будет ждать, что предоставляемая мной документация будет тоже в KOI8-R.

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