Думаю на пхп мало программ из-за того, что до сих пор популярен этот стереотип о непригодности PHP ни для чего, кроме как для «сайтиков». Приложения делают на HTML+js и никого не смущает что это все рисуется в браузере, но вот фраза «писать гуй на пыхе» почему то вызывает у многих недоумение. Мне это не понятно. От части свою роль играет факт отсутствия нормальной GUI библиотеки. Не будешь же для каждого приложения на пхп писать расширение с привязкой к сишному gtk.
Пожаловались, что у отрасли мало денег. Им нужно зарабатывать на прокате фильмов и реализации прав, но не получается этого сделать из-за наличия нелегальной дистрибуции фильмов и сериалов в интернете.
Может быть нужно наконец научиться качественно снимать фильмы используя все современные технологии? Тогда и желание будет «Сходить именно на этот фильм в кинотеатр, потому что смотреть его дома — это совсем не то!»
Большинство операторов уже предоставляют безлимитный мобильный доступ в интернет за довольно не маленькую денежную сумму и им этого мало? Как же тогда «выживают» обычные интернет-провайдеры, которые вообще не имеют никакой прибыли за звонки и смс?
Доступна для тестов сборка для линукса: ubuntu 14.04, Qt 5.2.1, PHP 5.6.13. Пока только так.
Если есть желание пощупать, то вот информация: http://phpqt.ru/pqengine/pqengine-on-linux
Задействовать qrc мне ничего не мешает. Но если его подключить, приложение получается Qt-зависимым, а значит либо требует наличия shared-библиотек Qt, либо требует статической линковки, а это в свою очередь означает, что программа увеличивается в размерах в два раза (ведь библиотека и так уже собрана статикой). В настоящее время при компиляции на выходе получается нативное win-приложение, которые использует возможности движка для работы с php файлами.
(статическая линковка с не LGPL кодом запрещена), поэтому я сейчас пользуясь этой лицензией требую выслать мне исходные тексты программы
Использование лицензии не наделяет вас или кого либо другого правом владеть исходным кодом. Продукт поставляется с заголовочными и объектными файлами библиотеки — делайте с ними что хотите: хоть на гитхабе публикуйте, хоть на луну отправляйте :)
Более того вместе с библиотекой поставляются исходники и объектные файлы статической сборки Qt, которые как бы намекают, что разработчик не вносил изменения в исходный код фреймворка. Какой не-LGPL-код вы имеете ввиду я не понимаю.
Тайна упаковки PHP кода — несостоятельна
Ну так это вы :) любой Ванька может открыть текстовый файл, который лежит в папке с приложением, и посмотреть его содержимое. А чтобы сделать прокси и посмотреть что отправляется в eval (который там, кстати, не используется) нужно как минимум знать, что приложение написано на php.
Я не зря написал про free(), потому что это действительно безопасный метод удаления объектов. Сейчас постараюсь рассказать что же тут произойдет. Когда мы вызываем free(), движок удаляет не только сам объект, но и все его дочерние объекты. А если объект — это виджет, то удаляется и установленный Layout, если таковой имелся. В вашем коде мы бы ничего не получили, в ответ. Даже сообщения об ошибке. Движок PQEngine в этом случае бы просто проигнорировал вызов метода, но сама переменная $layout все еще существует в памяти Zend Engine (если можно так выразиться). Существовать эта переменная будет до тех пор, пока она не «исчезнет» из области видимости, либо пока мы не запишем в нее что-нибудь другое.
Тестировать наличие утечек в подобных ситуациях я привык с помощью таймера:
$timer = new QTimer;
$timer->interval = 1;
$timer->onTimer = function() {
$w = new QWidget();
$layout = new QGridLayout;
$w->setLayout($layout);
$button1 = new QPushButton($w);
$layout->addWidget($button1,0,0);
$w->free();
};
$timer->start();
// запускаем код, открываем диспетчер задач и видим, что потребление памяти не возрастает ни на килобайт. Весьма непрофессиональный метод, но довольно эффективный :)
Теперь о unset(). unset() удалит лишь переменную, но qt объект останется в памяти. При этом мы с легкостью сможем получить доступ к этому объекту по его имени, либо через метод другого компонента, который бы возвратил ссылку на наш объект, например
$stack = new QStackWidget;
$widget = new QWidget;
$widget->objectName = 'myWidget';
$stack->addWidget($widget);
unset($widget);
$widget->free(); // возвратит ошибку, ведь мы удалили переменную, но
$stack->currentWidget->free(); // удалит наш виджет из памяти. Навсегда.
// кроме того к объектам можно обращаться через специальную функцию c($objectName):
$objectName = 'myWidget';
c($objectName)->free();
За код спасибо. Очень не хватает подобных тестов «с подковыркой».
Такого решения не было, все получилось само собой.
В основном к WinAPI привязан только модуль, позволяющий упаковывать и вытаскивать php-код из ресурсов приложения. Я вижу только один способ решить эту проблему — нужно лишь отказаться от статической линковки. Тогда можно будет пользоваться системой ресурсов Qt (qrc).
Если сделать так, то, как мне кажется, усугубится ситуация с возможностью создания кроссплатформенной библиотеки. Это проблему тоже можно было бы решить путем открытия исходных кодов, но тогда тайна упаковки php-кода будет раскрыта и достать исходник проекта из мало-мальски защищенного приложения ни у кого не составит труда.
Вот такой замкнутый круг получается.
А вообще для «безопасного» удаления любого qt-объекта имеется метод $object->free(). По идее само ничего удаляться не должно :) Да и движок очень узконаправлен, работает по большей части только с виджетами. Оберток над такими классами как QRect, QIcon, QVector и прочими нет и не предвидится, мне кажется что это уже лишнее. Все-таки движок предназначен больше для работы именно с GUI, а не с фреймворком Qt.
В этом плане утечек быть не должно. В движке реализовано собственное хранилище объектов. Каждый раз когда php обращается к объекту qt, это хранилище проверяется на предмет уничтоженных объектов как со стороны php, так и со стороны qt. Оверхед при этом не стучается, максимум что может произойти — пых вместо объекта получит null и выдаст соответствующее сообщение.
Возможность такая есть, движок поддерживает подключение php-расширений. Что для этого нужно:
в директории с приложением необходимо создать папку ext и скопировать туда нужную библиотеку. В вашем случае это будет php_sockets.dll. Библиотеку можно найти в дистрибутиве php, версия должна быть либо 5.4.45, либо 5.6.11 (в зависимости от того какой версией PQBuilder вы собирали приложение);
затем, для того чтобы эта библиотека подключилась, в директории с приложением создаем текстовый файл с именем pqengine.ini и со следующим содержимым:
extension="php_sockets.dll"
pqengine.ini — это тот же самый php.ini
Не буду обманывать на счет того «как в PyQt» оно или нет, честно — не знаю. Я скачивал PyQt в надежде почерпнуть что-то полезное для себя, но не смог этого сделать в силу своих незнаний Питона.
Все классы — это действительно обёртки над Qt-шными, которые предназначены для того, чтобы расшарить доступ к не-INVOKABLE методам и за одно привести их входные и выходные значения к примитивным типам, с которыми работает PHP (int, char, bool...). Доступ к объектам со стороны PHP осуществляется через магические методы (__call, _set...), предоставляемые Zend'ом, а финальный вызов методов происходит через метосистему Qt. Если посмотреть заголовочные файлы движка PQEngine, можно увидеть, что в обертках все методы объявлены с макросом Q_INVOKABLE.
Насчет подводных камней вопрос очень интересный и двоякий.
Если говорить о разработке приложений с использованием этой библиотеки, то тут пожалуй самое страшное то, что возможны утечки. Именно при работе с объектами фреймворка Qt. Боролся я с ними долго и усердно, но не факт что искоренил их во всех местах.
Если говорить о разработке самой библиотеки, то тут в голову приходят сразу 2 момента:
Непереносимость библиотеки на другие ОС. Слишком тесно все завязалось вокруг WinAPI, но в принципе, при желании «окросплатформеннить» её вполне реально.
Отсутствие расширяемости библиотеки в пользу её компактности. Из-за использования статической линковки с Qt написать какое-то дополнение достаточно проблематично. На счет этого уже было несколько идей, например, вынести из движка некоторые классы в подключаемые по требованию пользователя модули. Ну как в самом Qt — нужна работа с виджетами? Подключай QWidgets, нужна работа с сетью? Подключай QNetwork и т.д.
Думаю, если библиотека будет развиваться дальше, то её компактность рано или поздно перестанет быть оправданной, именно тогда она и будет разбита на составные части подключаемые по желаю разработчика.
Этот пост должен был нести добро и радость php-шникам, но тут пришли вы и перекрасили всё в серый цвет. Зачем же вы так? :)
Рассказывать о достоинствах PHP и его преимуществах перед другими языками будет не уместно, да и я рискую быть закиданным помидорами (а то и чем потяжелее), но все же — быстро склепать какую-нибудь безделушку с возможностью выхода в интернет без мозголомки, да еще и обрисовать вокруг этой безделушки вполне себе функциональную форму вполне реально.
Конечно, что-то достаточно серьезное на этом не напишешь, хотя попытки были… В любом случае это не мне решать, думаю тот, кого заинтересует данная библиотека найдет ей применение.
Дизайн с логотипом хабра, конечно, симпатичный, но насколько я знаю, буквенно-цифровые надписи, кроме названия банка и стандартных данных, на картах не допускаются.
В паблике этой программы нет. Из более свежего есть вот такое:
Думаю на пхп мало программ из-за того, что до сих пор популярен этот стереотип о непригодности PHP ни для чего, кроме как для «сайтиков». Приложения делают на HTML+js и никого не смущает что это все рисуется в браузере, но вот фраза «писать гуй на пыхе» почему то вызывает у многих недоумение. Мне это не понятно. От части свою роль играет факт отсутствия нормальной GUI библиотеки. Не будешь же для каждого приложения на пхп писать расширение с привязкой к сишному gtk.
Может быть нужно наконец научиться качественно снимать фильмы используя все современные технологии? Тогда и желание будет «Сходить именно на этот фильм в кинотеатр, потому что смотреть его дома — это совсем не то!»
Если есть желание пощупать, то вот информация: http://phpqt.ru/pqengine/pqengine-on-linux
Использование лицензии не наделяет вас или кого либо другого правом владеть исходным кодом. Продукт поставляется с заголовочными и объектными файлами библиотеки — делайте с ними что хотите: хоть на гитхабе публикуйте, хоть на луну отправляйте :)
Более того вместе с библиотекой поставляются исходники и объектные файлы статической сборки Qt, которые как бы намекают, что разработчик не вносил изменения в исходный код фреймворка. Какой не-LGPL-код вы имеете ввиду я не понимаю.
Ну так это вы :) любой Ванька может открыть текстовый файл, который лежит в папке с приложением, и посмотреть его содержимое. А чтобы сделать прокси и посмотреть что отправляется в eval (который там, кстати, не используется) нужно как минимум знать, что приложение написано на php.
Тестировать наличие утечек в подобных ситуациях я привык с помощью таймера:
Теперь о unset(). unset() удалит лишь переменную, но qt объект останется в памяти. При этом мы с легкостью сможем получить доступ к этому объекту по его имени, либо через метод другого компонента, который бы возвратил ссылку на наш объект, например
За код спасибо. Очень не хватает подобных тестов «с подковыркой».
В основном к WinAPI привязан только модуль, позволяющий упаковывать и вытаскивать php-код из ресурсов приложения. Я вижу только один способ решить эту проблему — нужно лишь отказаться от статической линковки. Тогда можно будет пользоваться системой ресурсов Qt (qrc).
Если сделать так, то, как мне кажется, усугубится ситуация с возможностью создания кроссплатформенной библиотеки. Это проблему тоже можно было бы решить путем открытия исходных кодов, но тогда тайна упаковки php-кода будет раскрыта и достать исходник проекта из мало-мальски защищенного приложения ни у кого не составит труда.
Вот такой замкнутый круг получается.
extension="php_sockets.dll"pqengine.ini — это тот же самый php.ini
Все классы — это действительно обёртки над Qt-шными, которые предназначены для того, чтобы расшарить доступ к не-INVOKABLE методам и за одно привести их входные и выходные значения к примитивным типам, с которыми работает PHP (int, char, bool...). Доступ к объектам со стороны PHP осуществляется через магические методы (__call, _set...), предоставляемые Zend'ом, а финальный вызов методов происходит через метосистему Qt. Если посмотреть заголовочные файлы движка PQEngine, можно увидеть, что в обертках все методы объявлены с макросом Q_INVOKABLE.
Насчет подводных камней вопрос очень интересный и двоякий.
Если говорить о разработке приложений с использованием этой библиотеки, то тут пожалуй самое страшное то, что возможны утечки. Именно при работе с объектами фреймворка Qt. Боролся я с ними долго и усердно, но не факт что искоренил их во всех местах.
Если говорить о разработке самой библиотеки, то тут в голову приходят сразу 2 момента:
Думаю, если библиотека будет развиваться дальше, то её компактность рано или поздно перестанет быть оправданной, именно тогда она и будет разбита на составные части подключаемые по желаю разработчика.
Рассказывать о достоинствах PHP и его преимуществах перед другими языками будет не уместно, да и я рискую быть закиданным помидорами (а то и чем потяжелее), но все же — быстро склепать какую-нибудь безделушку с возможностью выхода в интернет без мозголомки, да еще и обрисовать вокруг этой безделушки вполне себе функциональную форму вполне реально.
Конечно, что-то достаточно серьезное на этом не напишешь, хотя попытки были… В любом случае это не мне решать, думаю тот, кого заинтересует данная библиотека найдет ей применение.
Flash: WIN 18,0,0,194 x86-32 PlugIn
OS: Windows 8.1 32-bit
Browser:
дальше ничего не определилось. При нажатии на кнопку Run calc.exe флеш крашится: Shockwave Flash has crashed.
Chrome 43.0.2357.130 m