Python & GUI
кто имеет опыт? посмотрел в сторону kivy, но что-то оно сыроватое, и их галлерея приложений
не впечатлила.
имеется ввиду создание не игры, не апп, а "простого" десктоп-приложения. с табличками, кнопочками, списками, комбобоксами... хочется, чтобы все это можно было без особого напряга стилизовать как-то, чтобы не казенно выглядело.
не спрашивать, почему пайтон. не отвечу : )
pyGTK
https://python-gtk-3-tutorial.readthedocs.io/en/latest/
Здравствуйте,
К сожалению хороших примеров посоветовать не возьмусь. Я инсталирую с++ дистрибутив и смотрю примеры там.
Справочник по параметрам методов есть весьма приличный почты везде (вот, к примеру: https://docs.wxpython.org/), но толку от него не много (так, подглядеть что забылось - не больше. Для изучения - не достаточно).
Чтобы как-следует проникнутся - полезны либо туториалы (вот, к примеру: https://wiki.wxpython.org/) либо примеры использования (к-сожалению только с++, во-всяком случае я аналогичного набора примеров для Python не знаю. https://github.com/wxWidgets/wxWidgets/tree/master/samples).
Еще, эти примеры помогают ответить на вопрос, возможно ли какой-то елемет уплавления нестандартно использовать, и как оно приблизительно будет выглядеть. Вот к примеру с "табами" (notebook). Как по-другому кроме примера обяснить и показать еффект от применения с разными настройками
- я не знаю. Думаю, мейнтейнеры задавались схожими вопросами и пришли к выводу, что пример - наилучший метод. Еще и скопипейстить можно, частично.
Если у Вас есть опыт Qt или MFC - будет не сложно.
Мне вначале был не понятен подход с "сайзерами" и расспостранением сообщений по елементах управления, и вообще - по приложению. Примеры исспользования помогли (вот несколько туториалов с коментариями: https://wiki.wxpython.org/SizerTutorials, https://wiki.wxpython.org/UsingSizers).
Если будете серйозно заниматся - обратите внимание на исспользование XRC-рессурсов. Я вначале как-то "проскочил", потом поверить не мог что парился много зря, загружая ресурсы динамически.
Из недостатков именно питоновского решения - невнятный деплоймент при неообходимости сокрыть исходный код.
Из других недостатков, чисто субективно - недооцененность весьма вдумчиво спроектированной, с большим потенциалом для масштабирования платформы. Думаю, embedded даст ей второй шанс (если сообщество к тому времени не разбежится).
Также, контролы таблиц могли-бы быть немоного "умнее". Как по-мне - много ручной рабоиы. Несколько раз нехватало елементов для отображения графиков. Есть несколько сторонних альтернатив, но в самой библиотеки их нету.
С кросплатформенной стороной библиотеки я знаком слабо. Файловые операции, сокеты, контейнеры(который в самой библиотеке есть), юникод - все отлично переносится и компилируется (в Вашем случае не актуально, конечно). С пайпами не пробовал.
Сделал всего одну попытку с пользовательским интерфейсом (ради спортивного интереса). На Linux на GTK все выгладело отвратительно, как обычно. Я большего и не ожидал. Решил инвестировать время по-мере спросса. Спросса - не было :)
Успехов!
в общем, поигрался с некоторыми, решил, что самое простое будет Tkinter.
It is a thin object-oriented layer on top of Tcl/Tk.
выглядит не таким сырым, как остальные потуги создать "Python GUI", но все равно раздражает многое. с каждой ферней приходится долго разбираться. очередная заморочка - scrollbar. привык в так сильно ругаемом майкрософте, что это - property контрола, в котором используется, и по умолчанию виден только когда нужен, т.е. когда есть неотображаемая область. но вот сейчас имею в Tkinter. treeview widget, прицепил к нему скроллбар, она работает, но он виден постоянно, даже если контрол пустой. гуглю, чтоб найти, где включить нужный режим, нахожу массу примеров, где демонстрируют скроллбар, заполняя список заведомо большим количеством элементов. т.е. это - недоработка.
уверен, что в Tcl/Tk, надстройкой к которому Tkinter.является, ситуация аналогичная. нужно, что ли, определять геометрию всех элементов, вычислять размер занимаемой области и сравнивать с размером поля?
можно, конечно, с этим жить, но ощущение, что работаешь с чем-то наскоро на колене слепленном. вот такие они, бесплатные штучки...
Здравствуйте,
Вот, косательно скролбара: https://tkdocs.com/tutorial/text.html (раздел "Scroling").
Можно включать и отключать скролбар в зависимости от того виден ли желаемый текст или - нет
You can also ask the widget to ensure that a certain part of the text is visible. For example, if you've added more text to the widget than will fit onscreen (so it will scroll) but want to ensure that the top of the text rather than the bottom is visible, call the "see" method, passing it the position of the text (e.g. "1.0").
Успехов!
Сожалею, что не подошел wxWidgets (wxPython). Обратите внимание ск. там всего, по-поводу того-же скролбара https://wxpython.org/Phoenix/docs/html/wx.ScrollBar.html
ну да, слова написанные я много где находил, но примера, как создать ПРОСТО что-то вроде листбокса со скроллбаром, который появляется, когда все элементы уже не помещаются в область отображения, и исчезает, когда отображено все содержимое.
что касается wx, то я от него отказался, когда увидел, что создание элемента, который я привык называть ListView, сопряжено с танцами и бубнами. нашел пример, где это осуществляется с помощью выкручивания рук элементу grid. в tk такого элемента также нет, но он довольно просто реализуется с помощью treeview, без лишнего дописывания.
бесплатное "комьюнити" - не лучшая команда для разработки чего-нибудь стоящего. посмотрите, как выглядят скроллбары в эклипсе, например. это как мой коврик под дверью. вернее, его отсутствие. вместо него лежит кусок неровно отрезанного старого тэппихи.
предполагалось, что когда-нибудь найду время/желание и заменю на что-нибудь красивое/удобное. так же и с этими бесплатными приложениями, разработанными группой энтузиастов. проблема в том, что к ним нельзя прийти и сказать: ребята, что за херня! я плачу деньги, и хочу, чтобы здесь лежал коврик, а не говняный кусок теппиха! если не платишь, то или пользуйся чем есть, или дальше туда где что-то лучшее.
хочу спросить не совсем по теме, но ветку открывать новую не хочу, т.к. если кто-то знает, то вся ветка будет из двух постов: этого и ответа.
если вы пишете много на пайтоне, у вас наверняка имеется много "своих" пакетов, используемых в разных проектах. как вы все это организуете? "устанавливаете" свои пакеты через pip?
спрашиваю потому, что уперся в этот вопрос. у меня в эклипсе (pydev) имеется два проекта. в одном из них - package, который я использую также во втором проекте. пока в эклипсе отлаживаешь - без проблем: где-то в меню находишь, как сконфигурировать reference на проект, и можно делать import оттуда. но идем в командную строку, заходим в директорий, где главный файл второго проекта, запускаем его на выполнение (python mainfile.py), он запускается, но тут же вылетает, сообщая, что не может найти package.
расскажите, как вы организовываете ваши projects и packages.
думаю, нашел правильное читалово. самый примитивный способ работает, а мне пока большего не нужно. на PyPI пока соваться не с чем. привожу ссылки, может кому пригодится
https://python-packaging.readthedocs.io/en/latest/
https://setuptools.readthedocs.io/en/latest/
еще такая интересная статейка попалась:
https://stackoverflow.blog/2017/09/06/incredible-growth-py...
особенно тем, кто помоложе, советую не пропустить тренд. еще лет 10 назад практически не попадалось предложений работы с требованием пайтон, а сегодня количество таких растет как грибы. может через несколько лет заменить жаву. сперва заменит ее в университетах, затем и на практике.
Никаких шансов заменить яву у питона нет. Преимуществ у него в больших проектах нет. Быстренько слепить что-то - запросто.
За рост можно благодарить тот же тензор флоу. На питоне почему-то модно стало вечно глючащие не особо качественные поделухи на тему нейронных сетей и нлп лепить.
может и никаких. а может быть и есть какие-то, будуще только может показать. как и сама джава, задуманная когда-то для программирования игрушек. кто ей тогда мог предсказать такое распространение?
были, помню, и языки, которым прочили большое будущее (ада, например, пиэл один, ... ), но которые сегодня помнят немногие.
вспомним историю завоевания рынка майкрософтом. а ведь ibm ms-dos, затем os/2, были по крайней мере не хуже продуктов майкрософт (os/2 вообще нельзя сравнивать с виндоуз 3.х, 95 и пр). а вон оно как повернулось.
ведь в принципе написать можно все что угодно на любом из языков программирования (почти, конечно : ). другой вопрос, насколько на одном будет сложнее, чем на другом, и насколько нас устроит результат. но это определяется не только свойствами языка, а и многими другими условиями.
пайтон - это, похоже, очередная попытка создать язык для неинформатиков. как когда-то фортран для ученых: каждый за неделю-две мог свои вычисления с логарифмической линейки перенести на фортран. с абсолютного нуля. пайтон чем-то похож. освоить такой язык будет, думаю, проще, чем с/с++, и джаву даже. ну а говнокод можно тем более на любом языке сваять, и такого - большинство : )
при определенных условиях пайтон может получить такое развитие, которое ему позволит стать инструментом, с помощью которого неинформатики смогут решать свои конкретные задачи. ведь спрос на информатиков растет и будет продолжать расти, а их количество ограничено количеством мозгов, способных это все воспринимать. согласитесь, способности у всех природой распределены неодинаково, и процент способных не растет с развитием прогресса.
в прикладных областях также требуются способные головы, и больше, чем их есть, поэтому задача совместить в одной голове прикладника и информатика - очень актуальна.
"Вы просто не умеете их готовить." (с) Альф
Гавнякать можно на любом языке, и от кривых ручек не спасет ни java, ни c++. У меня вот, например, опыт прямо противоположный - на текущем проекте долго приходилось вступать в жесткие половые сношения с либой, нейросетью на джаве, для классификации и лемматизации слов. Было и криво и глючно, но легаси не позволяло от нее избавиться. И как только перешли на фейсбуковский fasttext на python - все наконец заработало как надо. А да, еще и быстрее в разы.
Низкий порог базового вхождения в язык, еще не означает, что каждый умеющий писать на питоне, на уровне if/else уже его знает.
Как по мне (до python писал на c#) - все, что в java, или том же c# сложнее для освоения, чем в python - это только сама экосистема языка и развертывание.
p.s. подкину бородатый баян )
- Why Java is so...
- Popular?
- SLOW!!!