вопросы по: текущее состояние программирования GUI с Python - PullRequest
21 голосов
/ 02 апреля 2009

Недавно я немного поработал над изменением графического приложения Python, использующего виджеты wxPython. За последние шесть или семь лет я экспериментировал с Python, но это был первый раз, когда я работал с графическим интерфейсом. Я был довольно разочарован тем, что кажется текущим состоянием программирования графического интерфейса на Python. Мне очень нравится сам язык Python, это забавное изменение по сравнению с программированием на Delphi / ObjectPascal, к которому я привык, безусловно, значительное увеличение производительности для задач программирования общего назначения. Я хотел бы перейти на Python для всего.

Но wxPython - это огромный шаг назад от чего-то вроде Delphi VCL или .NET WinForms. В то время как сам Python предлагает хороший выигрыш в производительности от программирования более высокого уровня абстракции, wxPython используется на более низком уровне абстракции, чем VCL. Например, я потратил много времени, пытаясь заставить объект списка wxPython вести себя так, как я хотел. Просто для добавления сортируемых столбцов потребовалось несколько шагов, интенсивно использующих код: один для создания и поддержки теневой структуры данных, обеспечивающей фактический порядок сортировки, другой для возможности отображения графических треугольников-сортировок-направлений в заголовке столбца и была еще пара, я не помню. Все эти подверженные ошибкам шаги можно выполнить, просто установив значение свойства с помощью моего компонента сетки Delphi.

Мой вывод: в то время как Python обеспечивает большой прирост производительности за счет повышения уровня абстракции для большого числа кодов общего назначения, wxPython на несколько уровней абстракции ниже , чем инструменты графического интерфейса, доступные для Delphi. Итоговый результат: программирование на GUI на Delphi происходит намного быстрее, чем на GUI на Python, а полученный интерфейс на Delphi все еще более отточен и полон. Мне не кажется преувеличением сказать, что программирование на Delphi GUI в 1995 году было более продвинутым, чем программирование на Python GUI с использованием wxPython в 2009 году.

Я провел некоторое исследование других фреймворков Python GUI, и, похоже, что они не были значительно лучше, чем wxPython. Я также провел минимальное исследование графических формирователей графического интерфейса для wxPython, которые могли бы немного улучшить ситуацию. Но в большинстве отчетов эти решения содержат ошибки, и даже отличный formbuilder не учел бы мои основные претензии к wxPython, которые заключаются просто в том, что он имеет меньше возможностей и, как правило, требует от вас программирования на графическом интерфейсе гораздо более низкого уровня абстракции, чем я используется с VCL Delphi. Некоторое быстрое изучение предлагаемых решений Python Gui-Dev (http://wiki.python.org/moin/GuiProgramming), честно говоря, несколько удручает человека, привыкшего к Delphi или .NET.

Наконец, у меня есть пара вопросов.

Во-первых, я что-то упустил? Есть ли какое-нибудь решение для разработки на Python, которое можно сравнить с программированием на VCL или WinForms? Мне не обязательно беспокоиться, если это не совсем соответствует VCL Delphi. Я просто ищу что-нибудь из той же лиги.

Во-вторых, может ли IronPython быть направлением? В основном я пытался не пить .NET koolaid, но, возможно, IronPython дает мне причину, чтобы наконец сдаться. Даже тогда, полностью ли IronPython интегрируется с WinForms, или мне нужно было бы, чтобы сами формы поддерживались c # или vb .сеть? Мне кажется, что это определенно имеет место с SharpDevelop и MonoDevelop (то есть, IronPython не может быть использован для создания графического интерфейса во время разработки). VS.NET полностью интегрирует IronPython с GUI-билдингом?

Мне действительно кажется, что Python мог бы «захватить весь мир» способом, подобным тому, как это делал Visual Basic в начале 1990-х годов, если появилось какое-то замечательное новое решение для создания графического интерфейса для Python. Только на этот раз с Python у нас будет совершенно новая парадигма быстрого, кроссплатформенного и открытого исходного кода графического программирования. Разве корпорации не сожрут это? Да, я знаю, что веб-приложения в настоящее время находятся в центре внимания, поэтому отличное решение Python-gui не создаст такую ​​же революцию, как когда-то делал VB. Но я не вижу исчезновения графического программирования, и мне хотелось бы получить хорошее современное решение с открытым исходным кодом, высокого уровня.

Ответы [ 9 ]

12 голосов
/ 02 апреля 2009

кажется, что вы жалуетесь на wxPython, а не на сам Python. попробуйте pyQt (или это qtPython?)

но и wxPython, и pyQt - это просто привязки Python к библиотеке C / C ++ (соответственно), так же (концептуально) низкий уровень, как и у оригиналов.

но Qt намного превосходит wx

5 голосов
/ 02 апреля 2009

PyQt является привязкой к Qt SDK от Nokia, а сам PyQt поставляется компанией под названием RiverBank .

Если лицензия для вас не важна, вы можете использовать PyQt под лицензией GPL или заплатить немного денег за коммерческую лицензию.

PyQt сейчас связывает Qt 4.4.

Qt - это не просто графический интерфейс, это полный C / C ++ SDK, который помогает с сетью, xml, media, db и другими вещами, а PyQt переносит все это на python.

С PyQt вы будете использовать Qt Designer и перенесете файл .ui в файл .py с помощью простой командной строки.

В Интернете вы найдете множество ресурсов о PyQt и хорошей поддержке со стороны различных сообществ, а также даже опубликованные книги по PyQt.

Многие предложения считают, что у RiverBank нет другого выбора, кроме как выпустить следующую версию, которая будет зависеть от Qt 4.5 под LGPL, мы ждем:).

Другим решением является Jython с Java Swing, который очень легко и элегантно написать (особенно в JDK 6), но не хватает ресурсов в Интернете.

3 голосов
/ 03 апреля 2009

dabo выводит программирование wxPython на более высокий уровень, чем то, что вы ищете.

3 голосов
/ 02 апреля 2009

Возможно, вы захотите взглянуть на Jython (Python на Java VM). Он очень похож на Iron Python, и вы можете перейти к .Net koolaid.

2 голосов
/ 03 апреля 2009

Краткий ответ: не пытайтесь Tkinter - у него есть все проблемы, описанные выше.

Длинный ответ: Tkinter бесполезен для больших программ. Обработка различных частей с этим каким-то образом неизменно вырождается в жонглирование (что никогда не происходит иначе), и полученный результат не выглядит естественным или особенно отточенным.

2 голосов
/ 02 апреля 2009

Возможно, вам придется использовать .net или java pythons, но сначала проверьте это и посмотрите, соответствует ли оно вашим требованиям:

Киви

0 голосов
/ 02 апреля 2009

Существует Wax , целью которого было создание более питонического интерфейса для wxWidgets, но, похоже, его разработка застопорилась.

0 голосов
/ 02 апреля 2009

Мы были очень рады использовать Python.Net для создания наших пользовательских интерфейсов в WinForms и использовать CPython для Presenter, Model. IronPython также является хорошим инструментом, если вы хотите использовать Python для Windows.

0 голосов
/ 02 апреля 2009

Вы правы, wxPython определенно может быть улучшен. Но я думаю, что Робин Данн проделал большую работу до сих пор

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...