Консоль з увімкненим X-сервером

[lenier]

Є зовнішній пристрій (цифорвий термометр). Фірма-виробник підтримує зняття температури (з подальшим присвоєнням значення змінній) тільки на Python'і, PHP і Perl'і. Треба, щоб графічне середовище (певна програма) дозволяла користувачеві змінювати критичні значення температури, і у випадку перевищення цього значення виводила повідомлення.

Проблема, з якою я зустрівся, полягає в тому, що графічні програми (я розглядав варіант PHP-GTK) очікують на дії користувача (натискання кнопки, зміна розміру вікна тощо), а мені треба, щоб вони реагували на якусь внутрішню (програмну) подію (перевищення критичного значення змінної).

Тому я надумав таке:
1. В скрипті на PHP працює цикл, який кожні 20 сек. зчитує дані з датчика і перевіряє в базі значення критичної температури.
2. Цей самий скрипт запускає графічну оболонку (GTK) і зберігає PID.
3. З графічної оболонки користувач може змінити значення критичної температури і зберегти в базу.
4. У випадку перевищення критичної температури скрипт призупиняє процес (kill STOP) і виводить повідомлення. У випадку натискання користувачем кнопки OK скрипт закриває повідомлення і продовжує процес (kill CONT).
5. Все це завантажується в консоль за допомогою init.d-скрипта так, щоб користувач не мав змоги вийти за межі GTK-програми.

Якщо все це можна зробити з GTK, підкажіть, як? PHP взяв як мову, яку більш-менш знаю (хоча заради такої справи ладен вивчити Python). Чи може проблема в тому, що я за це взявся?  

[delenn]

Ваш підхід жахливий. Це елементарно робиться засобами gtk/glib.

Алгоритм має виглядати приблизно так. Основний UI працює в MainLoop. Монітор зовнішніх повідомлень - в іншому треді, теж в циклі; при отриманні повідомлення, воно десеріалізується там же і змінює параметри UI. Тоді можна обійтись без постійних перезапусків.

Що варто почитати:

• Міжпроцесова взаємодія. Семафори, пайпи, іменовані пайпи. З вашого посту я роблю висновок, що ви про це нічого не знаєте. Окрім сигналів.
• glib, в основному gobject, де імплементовано API для роботи з багатопотоковими графічними інтерфейсами.
• php-біндінги мені не знайомі, тому можу порадити або pygtk, або gtkmm (якщо не бажаєте писати на C).

[kalina]

5. Все це завантажується в консоль за допомогою init.d-скрипта так, щоб користувач не мав змоги вийти за межі GTK-програми.

Не треба так робити. Для цього є autologin + ~/.xinitrc та/або ~/.xsession.d/

Якщо все це можна зробити з GTK, підкажіть, як? PHP взяв як мову, яку більш-менш знаю (хоча заради такої справи ладен вивчити Python). Чи може проблема в тому, що я за це взявся?  

Якщо вже php - то більш логічно робити це як інтранет-програму. Для відпрацювання асинхронних подій рекомендую подивитись у бік технології Ajax. Почати можна, приміром, з http://www.ibm.com/developerworks/ru/library/wa-ajaxintro1/index.html

[lenier]

Що варто почитати:

• Міжпроцесова взаємодія. Семафори, пайпи, іменовані пайпи. З вашого посту я роблю висновок, що ви про це нічого не знаєте. Окрім сигналів.
• glib, в основному gobject, де імплементовано API для роботи з багатопотоковими графічними інтерфейсами.
• php-біндінги мені не знайомі, тому можу порадити або pygtk, або gtkmm (якщо не бажаєте писати на C).

Колись вчився програмувати на C++ в середовищі Borland Builder на офтопіку (писав телефонний довідник), там щось читав про семафори і нитки, але тоді цього не треба було, то я толком і не знав, з чим його їсти.

Враховуючи те, що графічне середовище (програма) для користувача вже є (написана на Pithon'і з вихідними кодами), плюс виробник термометрів підтримує зняття інформації на Пітоні, то буду вчити Пітон.

P.s. Дякую за те, що підказали, в яку сторону копати.

[delenn]

Враховуючи те, що графічне середовище (програма) для користувача вже є (написана на Pithon'і з вихідними кодами), плюс виробник термометрів підтримує зняття інформації на Пітоні, то буду вчити Пітон.

В такому випадку, більш даю точне пояснення. Для ініціалізації багатопотокового UI, перед запуском MainLoop (gtk.main) зробіть gobject.threads_init(). Для опису треда використайте такий зразок:

Код: [Вибрати]

class UI_Thread(threading.Thread):
    def __init__(self, args):
        self.args = args
        super(UI_Thread, self).__init__()

    def ui_handler(self):
        #
        # Do some UI stuff here
        #
        pass

    def run(self):
        gobject.idle_add(self.ui_handler, self.args)Після створення об'єкту просто зробіть йому start(). Взагалі, загальне правило - ніколи не працюйте за об'єктами інтерфейсу з треда напряму. Тільки через gobject.

Щодо міжпроцесової взаємодії... не знаю всіх деталей проекту, але (для загального випадку) можу запропонувати fifo. Працювати так само як і зі звичайним файлом. Що даже зручно.

[BM]

Щодо міжпроцесової взаємодії... не знаю всіх деталей проекту, але (для загального випадку) можу запропонувати fifo. Працювати так само як і зі звичайним файлом. Що даже зручно.

OMG... А чим http://pyro.sourceforge.net/ не пішов? І взагалі на PyRo можна зробити так, що термометр буде собі окремим клієнт-сервером, до якого можуть собі чіплятись клієнт-сервери (для обміну внутрішніх повідомлень). Може бути й інша рахітектура (в залежності що курити і в яких кількостях). Щодо ґуя, то для Python єдиний wxPython (для wxWindows) найкращий, бо крім X11 ще-й паше на OSX та віндах (без X11) та додаткових бубнотанців. Крім того, таку програму можна «заморозити» через Py2Exe, Cx_Freeze та Py2App для відповідних платформ. Виходить товсто, але зате одним флаконом.

Ну це так, мої пару гривнів у дискусію — робіть як си хочете, зрештою... :-)

[Володимир Лісівка]

Вже реалізовано: D-Bus.

Можна написати свій графічний сервер, який запуститься, коли прийде повідомлення, і покаже користувачу повідомлення, а можна і скористатися існуючим (notify-send напр.).

[delenn]

І взагалі на PyRo можна зробити так, що термометр буде собі окремим клієнт-сервером, до якого можуть собі чіплятись клієнт-сервери (для обміну внутрішніх повідомлень).

Всім пішов, ви ж самі написали:

Може бути й інша рахітектура (в залежності що курити і в яких кількостях).

Хоча тут Володимир таки правий:

Вже реалізовано: D-Bus.

Воно справді сюди чудово пішло б. fifo таки не найкращий приклад, просто перше, що спало на думку - недавно в мене виникла така гірка необхідність.

Щодо ґуя, то для Python єдиний wxPython (для wxWindows) найкращий, бо крім X11 ще-й паше на OSX та віндах (без X11) та додаткових бубнотанців.

Якщо вже цілитись на кросплатформеність UI - то це Qt4 і тільки Qt4 Але lenier, здається, хотів gtk.

А підходів тут можливо реалізувати десятки. Було б бажання розбиратись.