Python съел мой графический интерфейс
Мысли о будущем Python и графических интерфейсов
Я смотрю на своих коллег, уже зная о неизбежности ситуации, и мои глаза закатываются, когда спор начинается заново:
«Я сказал вам, что могу написать этот код в два раза быстрее, в половину меньше строк, и он будет чище и читабельнее, чем когда-либо будет ваш! Python потрясающий! » - сказал тот парень.
«Что бы вы ни говорили, вы никогда не сможете создать интерфейс, который был бы вдвое хуже этого. Он не будет выглядеть красиво, и никто не захочет им пользоваться! " - ответил другой, - «Наверное, не сможет даже запустить на Windows», - пробормотал он себе под нос, уходя.
Несколько лет назад это был регулярный обмен мнениями между коллегами, и хотя они в основном бездельничали, в этом все же была доля правды. Независимо от своих возможностей, Python был в основном известен как «скриптовый» язык - не совсем для графических интерфейсов - и мир все еще искал ощущение нативной ОС в своих приложениях с графическим интерфейсом, которые были недоступны из Python без большой работы. .
Где мы сейчас находимся?
Перенесемся на несколько лет вперед, и у нас есть довольно много библиотек виджетов, доступных помимо tkinter или wxwidgets, наиболее известными из которых являются PyQt и Киви. У нас также есть хорошие приложения для конечных пользователей с богатым графическим интерфейсом, такие как, например, настольное приложение Dropbox.
Однако, хотя все эти модули реализовали виджеты своими уникальными способами, я утверждаю, что мы до сих пор не решили окончательно графический интерфейс в Python, особенно при проектировании для кроссплатформенности или при размышлениях о мобильных устройствах.
PyQT и гремлины лицензирования
Поскольку это один из наиболее часто используемых и многофункциональных модулей, вполне возможно относительно легко создавать достойные графические интерфейсы. Сама библиотека QT также доступна на других языках, таких как C ++, поэтому она уже знакома некоторым программистам. Он способен создавать виджеты, выглядящие как нативные, путем рисования их как изображений, и в некоторых случаях может обеспечить преимущество в скорости по сравнению с нативными.
Однако есть такая: Часто задаваемые вопросы о лицензиях QT
Извините, но если вам нужен раздел часто задаваемых вопросов, чтобы люди понимали, как они могут получить лицензию на ваш продукт на законных основаниях и при этом иметь возможность контролировать свою работу, тогда вы все еще живете в 90-х годах. На самом деле это не проблема, о которой я хотел бы беспокоиться, какой бы хорошей ни была ваша библиотека. Кроме того, природа самого Python представляет некоторые интересные сложности при рассмотрении распределения в таких ситуациях.
Учитывая открытость сообщества и популярность лицензионного кода MIT, я просто не считаю это жизнеспособным.
А что насчет Киви?
Kivy - очень умное решение, которое становится независимым от ОС за счет использования интерфейсов OpenGL для непосредственного рисования своих виджетов.
Эти ребята приложили огромные усилия и проделали хорошую работу. Они разработали свой собственный язык описания, чтобы помочь структурировать сложные среды, проделали работу по его функционированию на мобильных платформах, интегрировали новые парадигмы пользовательского ввода (например, жесты) и не имеют проблем с лицензированием.
В чем недостаток? Он отлично подходит для игр и небольших приложений, но мне сложнее использовать его для бизнес-приложений, которые должны представлять большой объем данных, например сложные таблицы.
Что теперь?
Смартфоны и мобильный мир сильно повлияли на ландшафт пользовательского интерфейса для каждой платформы. Людям нужны гладкие и интуитивно понятные интерфейсы, которые пробуждают творческий потенциал, как то, чего они привыкли ожидать от продуктов Apple и, в некоторой степени, Android. Они не обязательно оценивают ваше приложение по использованию нативных виджетов, на самом деле теперь они хотят, чтобы все выглядело так, как в Интернете с помощью CSS и HTML5.
Популярные библиотеки и системы шаблонов значительно эволюционировали за эти годы, эффективно демократизируя общие метафоры для взаимодействия с пользователем. Достаточно взглянуть на Bootstrap и Foundation или даже на Ionic и WordPress. Эти системы позволяют довольно легко и быстро создать красивый веб-сайт.
Сами веб-браузеры, а также язык JavaScript также продвинулись до уровня, обеспечивающего скорость и совместимость на уровне, которого раньше не было. Что, в свою очередь, привело к появлению одностраничных веб-приложений, которые перенастраивают себя, как если бы они использовали собственные виджеты вместо загрузки на отдельные отдельные веб-страницы.
В довершение ко всему, HTML5 и его тег SVG открыли передовую поддержку векторной графики. Вы видели, на что способен d3js? Затем есть WebGL, еще одна технология, на которую сейчас нацелены многие игровые движки, позволяющая разработчикам создавать производительные 3D-игры в вашем браузере.
Учитывая все эти достижения, я обнаружил, что пишу кучу кода JavaScript или HTML, чтобы обеспечить интерфейс для моего Python, и, как бы мне ни нравилось создавать красивые вещи, удобочитаемость и ремонтопригодность сильно страдают от этих языков.
В то же время я, кажется, повторяю те же шаблоны при создании этих интерфейсов, соединяя их с моим внутренним кодом и подключаю события, которые мне нужны, чтобы иметь работающее веб-приложение. И, конечно же, переключение между языками и методами кодирования может действительно испортить ваш стиль (или вообще лишить вас хорошего стиля). Поэтому я спрашиваю:
Почему бы не разработать пакет Python для взаимодействия с пользователями на основе всех этих технологий вместе взятых?
Было бы возможно? Я не говорю о другом веб-сервере, таком как Django или Pyramid, на самом деле я думаю, что сама идея Django и подобных фреймворков должна исчезнуть. Я считаю шаблоны громоздкими, трудными для чтения и непифоническими.
Я хочу написать код Python, который выделяет HTML и JavaScript, необходимые для этих интерфейсов, и я все еще хочу обрабатывать всю логику на Python. Я не хочу касаться каких-либо других слоев, если мне не нужны какие-то особые настройки виджетов. Я хочу автоматически использовать все необходимые мне библиотеки JS, такие как D3, DataTables, jQuery и т. Д., Все из моего кода Python. Я хочу, чтобы он был расширяемым, чтобы новые «виджеты» легко создавались поверх базовой платформы, а их использование было бы таким же простым, как импорт модуля. Я хочу, чтобы все это было кросс-браузерной поддержкой, и я хочу иметь возможность предоставлять это как автономное приложение.
Что я буду с этим делать?
Поскольку в последнем абзаце много «я хочу», я решил попробовать, как бы я это сделал. В следующей части этой серии, посвященной некоторым этапам разработки моего решения, взгляните на
Если у вас есть предложения или идеи относительно того, что вы хотели бы видеть или как вы хотели бы, чтобы это было реализовано, оставьте их в комментариях.
Если вам понравилась эта статья и вы хотите быть в курсе того, над чем я работаю, порекомендуйте ее, посетите tryexecptpass.org для получения дополнительных тем и подпишитесь на меня в Twitter.
