Блоги

14:18 09-04-2012

Virtuos86

Много букв, берегись читатель.
=====================================================================
Небольшая преамбула, вводящая в контекст дальнейшего повествования.
Некоторым моим знакомым известно, что некоторое время назад я был озадачен продолжением своего невнятного начинания: подкаста о Python for S60. Невнятного в силу отсутствия чётко выраженной мотивации для работы ним.
Как бы ни было текст для очередного выпуска был создан, но не облачён в чарующие (сарказм) обертоны моего голоса и, соответственно, не был выложен в публичный доступ.
И всё время до настоящего момента моя гадкая совесть на пару с эгоизмом периодически намекали, что так поступать нехорошо.
И я почти исправился! Светлая магия весны побудила меня опубликовать этот эпичный текст здесь, где достаточно заинтересованной публики (примерно 5-6 человек по моим скромным оценкам ;).
Если при чтении вы сделаете поправку на некоторую временнУю отдалённость описываемого текста от настоящего времени, а также то, что текст предназначался для озвучивания, вас не слишком озадачат манера его изложения и стиль.
Итак, приступим.
======================================================================
Волны гасят ветер, а понедельник начинается в субботу.

Доброго времени суток, уважаемые подслушатели.
Сегодня как раз суббота, а значит, как ни парадоксально, пора за работу.
За бортом минус тридцать по шкале господина Цельсия, а из ваших динамиков-наушников льется, надо полагать, четвертый выпуск подкаста Радио-Пайтон.
Для тех, кто не в курсе, этот подкаст посвящён порту языка программирования Python на мобильную платформу S60 от Nokia, построенную на базе операционной системы Symbian.
Порт этот именуется ПиЭС60 или ПайЭС60, как вам угодно.
Сегодня разговор пойдёт о версии 2.0.
Я зашел давеча на официальную страницу проекта на garage.maemo.org.
Пробежался по открытым багам и фичреквестам и вдохновился на разговор о чаяниях программистов, которым видимо не суждено уже сбыться, поскольку финальный релиз проекта вышел уже год назад.
Итак, начнём:
Я буду выделять паузами рассмотрение отдельных фич, дабы не смешивать всё ну совсем уж в одну кучу.
-------------------
Для начала поговорим о том, какие недостатки-недодатки люди видят в системном графическом интерфейсе, который напоминаю представлен модулем с зубодробительным именем "appuifw".
В-принципе, многие хотелки известны уже давно, ещё со времён старой доброй версии 1.4.
И, забегая вперёд, скажу, что они так же остались в итоге нереализованными и для второй версии. Грусть-печаль, да и только.
Ну что ж мы начинаем игру в бисер. Если вы не знаете, что это такое, то я как-нибудь расскажу об этом поподробнее.
Объект appuifw.app, предоставляющий доступ к индивидуализации интерфейса приложения -- как то телу, заголовку, подписям софтклавиш и привязкам колбэков к нажатиям на клавиши, так вот этот объект может иметь несколько табов-вкладок, между которыми можно перемещаться либо с помощью нажатия вправо-влево джойстика или замещаюшей его пятипозиционной клавиши, как дело обстоит на сенсорных смартфонах я, если честно не в курсе.
Итак, вкратце очень хочется иметь возможность задавать табы с иконками. В некоторых стандартных приложениях это используется и кашу совершенно точно не портит.
Как правило любой дополнительной функциональности привычных инструментов программисты рады. Оно и не мудрено. Улучшение и обогащение АПИ как подарок на новый год - в смысле приятное удовольствие, а не: "Опять свитер!? :(".
Но вернемся к вкладкам. Если приложение имеет более двух вкладок, то это должно отображаться стрелками, опять же как это и реализовано в стандартных приложениях.
И эта возможность, как ни странно, была добавлена. Если не ошибаюсь, это единственный закрытый фичреквест из всего списка. Поэтому я и рассматриваю его в первую очередь.
Ведь могут чертяки когда хотят!
Следующий на очереди объект appuifw.Text.
Уже не первому поколению мобильных питонеров хочется иметь возможность задавать цвет фона, вместо стандартного белого, например так, как позволяют это объекты appuifw.Canvas.
Я не знаю, видимо, есть какие-то ограничения, хотя на ум приходит модуль расширяющий возможности appuifw, а именно appuifw2.
На самом деле многие хотелки, такие как изменение подписей софтклавиш, богатую работу с текстом, в том числе и выделенным, даже поддержку определения языка локализации смартфона, если мне не изменяет память, улучшенный тип листбокса и нотификаций, и так далее и тому подобное, могли бы быть закрыты портированием на вторую версию PyS60 этого замечательного модуля.
Вернее полноценным портированием, потому что та глючная неполноценная версия, что есть сейчас ни на что серьезное не годится.
О помощи в этом деле просил в одном из последних фичреквестов сам автор модуля, Аркадиус Валигь. По совместительству он также автор редактора Пед, который является единственным известным мне проектом с хорошо продуманной внутренней архитектурой.
В общем, как ни крути фигура видная.
Но опять нужно констатировать, что финальный релиз Питона есть, а улучшенного appuifw нет.
Нельзя не упомянуть мою излюбленную особенность объектов Text. В них нет поддержки изменения языка ввода.
То есть в стандартных контролах таковая присутствует, достаточно лишь нажать звездочку-астерикс, выбрать пункт в меню и вот он список языков, а вот в объекте текст - никак.
Напоследок отмечу, что многие полезные мелочи, упомянутые мной ранее, реализованы в модуле msys, что автоматически переводит его в разряд мастхэвных, о чём я вас и уведомляю. Ещё раз - модуль msys.

Некоторые сенсорные смартфоны не имеющие программных софт клавиш в полноэкранном режиме дисплея имеют проблемы с доступом в меню Функции. Но, в полном соответствии с принципом питоновского Дзен "Особые случаи не настолько особы, чтобы влиять на правила", ожидать допилки модуля под таковые аппараты не приходится. Это просто надо иметь в виду программистам, и давать возможность обходиться другими средствами доступа к функционалу приложений. Если не изкоробки, то хотя бы по запросам трудящихся.
По неведомой причине объект appuifw.Form не имеет типа элементов 'код/пароль', хотя в общем-то задуман именно для организации хранения настроек приложений.
В пользу этого говорит хотя бы способ его использования, отличный от объектов других типов модуля. Что же нелогичного в хранении пароля в настройках? Да, есть возможнось задать соответствующий подходящий тип для запроса appuifw.query, но из элементов формы нельзя вызывать колбэки, максимум редактировать значения.
Обычный велосипед для обхода этого недостатка - практика использования двухстрочного листбокса. Этот объект позволяет использовать колбэк, вызывающийся при выборе элемента, с возможностью определения порядкового номера текущего элемента. Чего же боле?
В титуле элемента обычно задается описание параметра, а в дескрипшене значение этого параметра.
Учитывая возможность добавить в элемент левопозиционную иконку, можно смело и с удобством обходиться без объекта Форм.
Я собственно так и делаю.
Эмуляции нажатий клавиш была нужна всегда.
С появлением сенсорных аппаратов, пытливым умам потребовалась и эмуляция нажатий стилуса в заданных координатах.
С первым всё благополучно, хорошо знакомый модуль keypress для симуляции отправления операционой системе кейкодов нажатий клавиш уже есть под второй Python, также как и модуль rkeypress для симуляции уже сканкодов нажатий клавиш.
Модулей решающих вторую задачу мне не известно. Вся надежда на китайских камрадов.
Следующий недостаток, ставший почему-то камнем преткновения для разработчиков, это отсутствие прогресс-диалога и управляемого диалога ожидания. В системных приложениях опять же они есть, а python-разработчики вынуждены при необходимости велосипедить что-нибудь на topwindow.

Продолжая список урезанности графических контролов упомяну отсутствие для элементов листбокса автопрокрутки длинного текста, не помещающегося на дисплей. Хотя её можно реализовать некрасивым велосипедом, и то хорошо.
Мульти-селекшен лист с предустановленными значениями идёт в ту же категорию.
Поддержка других более распространенных графических форматов в листбоксах кроме довольно узкоспецифичных MBM-MIF была бы также хороша. Но её нет и я на этот раз не уверен, что это пожелание разумно.

Из списка фичреквестов я с удивлением узнал, что отсутствует поддержка тач-событий в glcanvas. Вопрос, зачем оно тогда нужно, повис в воздухе. Сенсорные смартфоны в пролёте?
После этого про поддержку тач-событий в topwindow не хочется даже заикаться.

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

Идея конструирования изображения из строки вместо сохранения в файл и открытия через Image.open() не нова и... не реализована до сих пор.
Регулировка яркости подсветки, в принципе решенная для PyS60 1.4 сравнительно недавно, предсказуемо заносится в разряд фич с непрогнозируемым сроком реализации.
HQ - high quality текст-ту-спиич, с возможностью загрузки разных языковых баз доступный на новых смартфонах - по описанию очень лакомая штучка и уж верно не чета машинному произношению известному по audio.say. Я бы и сам не отказался, если бы был доступен такой API.
Про такую вещь как отключение убийства приложения при нажатии на красную клавишу могу сказать, что она решается присвоением процессу приложения атрибута "системный". Как это сделать уже другой вопрос. Даю наводку - модуль msys.
А про такую как доступ к базе данных Журнала, например, чтобы можно было удалить пропущенные вызовы, скажу, что для этого и многого другого есть замечательный модуль scriptext. Правда смартфоны с Symbian 9.2 отдыхают, для них этот модуль не доступен. Подробнее можно узнать в АПИ РЕФЕРЕНС.
Поддержка PyQt.
Не нужно. Серьезно. Вон есть поддержка PyGame. Причём сделанная несколько оригинально. Я бы даже сказал маргинально, в том смысле, что обособленно от самого Python.

Поддержка перезагрузки смартфона из Python лично мне никогда не требовалась особо, тем более, учитывая, что в фоне постоянно висит несколько открытых приложений с не то, чтобы сильно важными данными, но которые не охота заново восстанавливать, открывать и т.д.. Тем не менее такая фича бесспорно нужна. И так же бесспорно, что в стандартных батарейках её не будет.
Поддержка специальных символов типа звездочки и решетки в отправлении телефонных вызовов. Ну попросту проверять счёт, например. Сейчас это, пардон, попаболь.
АПИ к веб браузеру, хотя бы дефолтному системному, чтобы можно было открывать вебстраницы. Есть один способ, но работает он немного странно. Впрочем этого достаточно.
А Вот если бы в Симбиан был аналог униксовых потоков ввода-вывода, чтобы можно было по-человечески передавать запускаемым приложениям команды, вот это было бы замечательно. Мечты-мечты.
Во втором PyS60 наконец-то появилась официальная возможность устанавливать рантайм языка и приложения на разные диски. Другое дело, что размер встроенной памяти девайсов перестал вызывать слёзы. Но всё равно это большой плюс.
Кто-то жаждет скрывать приложения из меню. Но имейте же совесть, граждане. Такие вопросы решаются прежде всего взломом системы (хотя я вам этого не говорил), и никаким боком к сабжу не относятся.

Безусловно хорошо было бы иметь возможность выбирать размер и качество записи видео. Вызывает недоумение тот факт, что в данный момент можно записывать лишь низкокачественное видео в разрешении 176x144. Пардон, это стандарт смартфонов седьмой версии симбиана, но никак не девятой.
Некий гик хочет поддержку инфракрасного порта, чтобы использовать с его помощью разные микрочипы.
И вообще всем хочется изкоробочной поддержки Pythonом всевозможных железок телефона, типа второй камеры, вспышки. Вполне понятные желания. Кто бы ещё их реализовал.
Кому-то мало того, что PyS60 2.0 основан на CPython 2.5.4, и он хочет поддержки CPython 2.6. Что можно сказать -- губа не дура, добро ещё не 2.7.

Хочется отправлять DTMF при активном голосовом вызове. На сенсорных девайсах с этим очевидный затык. Очень специфичная фича, и некостыльных путей её разрешения нет.
-------------------
Среди всякой шелухи обнаружились и довольно ценные идеи:
Как к примеру, просьба добавить поддержку ctypes. В комментировании не нуждается.

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

-------------------
Напоследок пара Лулзов:
К таковым безусловно относится пожелание не показывать в галерее изображения-ресурсы установленных в data/python приложений. Установи на директорию с изображениями атрибут "скрытый" с помощью вполне стандартного модуль os, и будет тебе счастье.

Некий оригинал спрашивает, не последует ли в скором времени начало порта PyS60 на WP7 (иными словами PyWP7 от Nokia).
Учитывая, что ВП7 закрытая ось можно предположить, что скорее выйдет ВП7Бэйсик, с возможностями пригодными для написания разве что калькулятора.
--------------------
Скоро сказка сказывается, а подкаст ещё быстрее.
Я прощаюсь с вами, и поздравляю с Новым Годом. С каким? Да хотя бы со Старым.
По крайней мере этот материал писался в канун праздника, но получился эдаким ленивым, с отложенным выполнением.
Что вам нужнее в Новом Году, вы знаете лучше меня, поэтому
Пожелаю вам больше подкастов, вкусных и разных.
До свиданья и да пребудет с вами Сила.