LINUX.ORG.RU

GUI в Python3

 , ,


0

1

Доброе утро, ЛОР!

Хотел попросить совета вот в каком вопросе. Пишится проект (двумя программистами) по клиент-серверной архитектуре. Требуется написать клиент с GUI. Степень красоты значения не имеет. Основные требования - кроссплатформенность, широкий набор виджетов (либо возможность сделать любой виджет самостоятельно без ковыряния в Си), а так же наличия биндинга для Pyhton3 (Python2 не предлагать!). Что можете посоветовать?



Последнее исправление: i_overdose (всего исправлений: 1)
Ответ на: комментарий от zJes

Не слушай маргиналов, только Qt (PyQt, PySide)

И пополни армию никому не нужных программ. Факт, на питоне и gtk есть полезняшки, на Qt — нет. ТС, не думай что ты будешь исключением.

baverman ★★★
()
Ответ на: комментарий от baverman

Питон3 и Gtk - уже сделали вмненяемые биндинги?
Да и так ли важно какой тулкит был использован, главное чтобы программа была. К тому же с кутей будет гораздо проще с кроссиспользованием.

zJes ★★
()
Ответ на: комментарий от zJes

Питон3 и Gtk - уже сделали вмненяемые биндинги?

GI. Других никогда и не будет.

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

Согласен, но почему в природе больше программ на гтк, говорит о многом.

baverman ★★★
()
Ответ на: комментарий от baverman

Да собстно ни о чем не говорит. Веяние моды, гнома, убунты... и отсутсвия в течении долгого времени LGPL у куте. :)
(Вот сколько раз слышал о PyQt, что использовать его не комильфо, лицензия им не та).

zJes ★★
()
Ответ на: комментарий от baverman

но почему в природе больше программ на гтк

Однако же 4.2 - больше всего программ наваяно наспех в visual studio, delphi или на вижуал бейсике. И во всех совершенно одинаково нельзя выделить мышью и скопировать надпись на любом text label, даже если там выводятся результаты - нет, только смотри, потому что задумываться о качестве инструментов - это не мейнстрим.

quiet_readonly ★★★★
()
Ответ на: комментарий от i_overdose

Прошу прощения, мне почему-то казалось... С чем-то спутал. Ж)

feofil
()

Браузер?

zz ★★★★
()
Ответ на: комментарий от baverman

Ну да, это компенсирует отсутствие нормальной официальной документации. :) Не волнуйся, ты просто инфу и готовый код на кутю не искал/не использовал, у тебя односторонний взгляд. :)
Чтобы писать пайкуте или пайсайд можно использовать стандартную доку по куте, которая ой как хороша.
Кстати, задумался, а я ведь ничего из пайгтк и не использую. Пример полезняшки можешь дать? :)

zJes ★★
()
Ответ на: комментарий от zJes

нормальной официальной документации

Сдается мне, ты тоже ее не нашел.

baverman ★★★
()
Ответ на: комментарий от baverman

Ну... знаешь, не фонтан выборка, для меня, брал посмотреть только гайм, все остальное вообще не знаю что такое. :)

zJes ★★
()
Ответ на: комментарий от anonymous

Anki

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

baverman ★★★
()
Ответ на: комментарий от baverman

Охотно верю, если бы было написано на пайкуте, были бы меньше нужны?
В общем, спор ни о чем... каждый выбирает сам на чем писать. Смотреть при выборе на то, что 1% > 0.9% как то странно.

zJes ★★
()
Ответ на: комментарий от anonymous

Эта штука сама по себе оправдывает наличие PyQt :)

vurdalak ★★★★★
()
Ответ на: комментарий от quiet_readonly

Однако же 4.2 - больше всего программ наваяно наспех в visual studio, delphi или на вижуал бейсике. И во всех совершенно одинаково нельзя выделить мышью и скопировать надпись на любом text label, даже если там выводятся результаты - нет, только смотри, потому что задумываться о качестве инструментов - это не мейнстрим.

это не качество инструмента, это - качество программиста. в gtk текстовые метки изначально не выделяемы (и имхо - это поведение правильное). хочется выделения - явно это укажи. если какой китаец, наспех ваяющий, не ослилил тулкит - это говорит только о качестве китайца

ananas ★★★★★
()

не хочу показать своё неуважение к Qt (мне оно нравится. теоретически), но практика с PySide у меня закончилась довольно быстро, после следующего эксперимента.

некоторая простейшая python-программа создавала HTTP-Client-объект (Qt`шный) и слушала событие на получение от него ответа — в асинхронном режиме. при этом сам объект ни где НЕ сохранялся (в ЯВНОМ виде) — ни в каких явных переменных python-программы.

в этом случае после наступления события изменения статуса этого Qt-объекта — python-программа сегфаултилась (что вообще есть ДИКОСТЬ для мира python).

тоесть по какойто причине похоже что срабатывал сборщик мусора Qt-объекта, из-за того то я в ЯВНОМ виде нет в python-программе ссылки на этот объект.

(но в НЕЯВНОМ же виде ссылка сёравно ДОЛЖНА БЫЛА сохранятся гдето!!! а если нет — то это охренеть как тупо!!)

вобщем после этого эксперимента сразу забил на PySide. даже баг-репорт не отправил. потому как не знаю как чётко сформулировать эту проблему, но эта проблема есть явно ДЕТСКОГО характера.

#P.S.: было это очень давно.

user_id_68054 ★★★★★
()

#P.S.: было это очень давно.

вот сёдня при наступлении ночи — возьму, да и ещё разок попробую провеси этот же эксперимент в Qt (PySide) ... посмотрим есть ли у них прогресс :)

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

(но в НЕЯВНОМ же виде ссылка сёравно ДОЛЖНА БЫЛА сохранятся гдето!!! а если нет — то это охренеть как тупо!!)

поясню что конкретно тупо.

тупо что event-driven-механизм (Qt`шный) берт на себя забачу отслеживания события изменения статуса некоторого Qt-объекта. но при этом сам не хранит внутри себя ссылку на этот объект.

как будто в стиле — «„„я отслеживаю статус — сам не знаю чего. но отслеживаю!““»

а в Tornado и Twisted (в ихних event-driven-циклах) — такого казуса не происходило.

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

Бгг... даже не пробуй, с таким подходом у тебя ничего не получится.

zJes ★★
()

Qt конечно. Я имел дело с PyQt и PySide. Второй вариант биндинга имеет небольшие отличия от PyQt, но работает не хуже. Любой из них вам подойдёт. Там даже в примерах была реализация кастомного контрола на python. С PyGtk тоже можно написать свой контрол, но и документация у PyGtk слабее, и примеров заметно меньше. А ещё прийдётся ковырять привязку к Cairo. PyQt однозначно логичней, проще и удобней.

lucentcode ★★★★★
()

Вею-интерфейс. Современно, модно, молодежно.

mopsene ★★★
()
Ответ на: комментарий от baverman

Все просто, изначально учил третий питон, поэтому проще сразу брать его, чем терять время на 2.х (да по моему и Гвидо что-то когда-то говорил о том, что витоге вторая ветка все равно скатится к третьей)

i_overdose
() автор топика

Gtk через pygobject

anonymous
()
Ответ на: комментарий от zJes

PyQt

это ваше пикутэ - бесформенное говно. я уже обломался когда обнаружилось, что далеко не все пробиндовано к сишной либе.

и да, кутешное апи - полный шлак, по сравнению с Gtk

anonymous
()
Ответ на: комментарий от quiet_readonly

Однако же 4.2

девушка, купите себе пачку глицина в аптеке

anonymous
()
Ответ на: комментарий от baverman

имхаю, пора бы прислушаться к веянию и таки признать устарелость второго шланга. за юникод-16 во всех полях - уже большое спасибо.

з.ы. люто бешено жду 3.3

anonymous
()
Ответ на: комментарий от zJes

Охотно верю, если бы было написано на пайкуте, были бы меньше нужны?

В общем, спор ни о чем...

твой фемоз уже задрал. если ты вообще не в курсе, что очевидно, то лучше молчи - сойдёшь за умного.

anonymous
()
Ответ на: комментарий от lucentcode

но и документация у PyGtk слабее

ничего что у PyQt документация тупо дерётся с сишной либы почти без никакой обработки? gi же изначально делается так, что сишная дока подходит для кодинга в питоне и любом другом языке.

anonymous
()
Ответ на: комментарий от anonymous

Вот именно, что почти без никакой обработки. А дьявол кроется в деталях. Писать на Python в стиле C - это неправильно. Это просто сорвёт крышу питонеру, не очень знакомому с C. А PyQt как раз подкупает тем, что с данной привязкой можно писать код практически в Ъ-python стиле. Я попробовал вначале PyGTK, затем PyQt. Второе мне показалось более адаптированным под работу с питоном. Не нужно писать практически сишный код на питоне, можно писать так, как привык. И пользоваться нормальной, написанной под python документацией. Это дело вкуса. Опытным специалистам по C и PyGTK будет удобен.

lucentcode ★★★★★
()
Ответ на: комментарий от Deleted

Все ждал, пока кто-нибудь предложит.

Имхо, кросплатформенней и искаробочней для питона не найти. Увы, местами TK слишком уж прост.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.