Van itt valaki, aki rendszeresen programozgat GUI-t, python3 alatt?

Szkriptek: Python, Perl, Bash, ...

Érdekelne, hogy van-e élő ember, aki rendszeresen készít GUI-s programokat python3-ban?
Ha van: milyen grafikus keretrendszert használ?

Az elsődleges gond, hogy python3 alatt kellene működnie, ami sok esetben problémás, mert a 2-es csomagok igen nagy hányada nem lett portolva, így nem tudom, a grafikus keretrendszerekkel mi a helyzet.

A másodlagos a tisztességes/elfogadható doksi. Kezdtem a tkinter-rel, de már az elején elakadtam, mert egészen alapvető dolgok nincsenek normálisan dokumentálva a megtalált leírásokban.
Előszedtem a Qt-t.
PyQt5 lenne most az aktuális, épp csak pár felszínes tutorial áll rendelkezésre és mellette a Qt5 dokumentáció, mert a PyQt5 sajátjában csak hivatkozások vannak a C++ doksira.
PySide2 lenne az alternatíva, de Ubuntu LTS (16.04) alatt csak PPA-ból lehetne feltenni valamit, amiről egyelőre nincs bővebb infóm, apt, snap, pip3 nem tud róla.

Szóval érdekelne, használ-e itt valaki ilyesmit és ha igen, akkor mit?

  • 5481 megtekintés

( kantal | 2018. 03. 16., p – 23:12 )

Hébe-hóba kisebb Tkinter-es programokat készítek, de inkább csak a magam szórakoztatására. Előny: egyszerűen lehet benne viszonylag komplex UI feladatokat megoldani. Hátrány: csak 2D, nincs OpenGL.

A PySide2-őt én is néztem korábban, de elvesztettem iránta a bizalmamat, mert úgy tűnt, hogy nagyon lassan jut el egy kiforrott állapotba.

Sokan használnak wxPythont, de én nem ismerem; talán a Tkinterrel azonos tudású.

PgObject: ez kiforrott tűnik, meg bonyolultnak, de nem foglalkoztam vele.

Kivy: tervezem, hogy megnézem, egyszer. Előny: 3D, Androidon is fut. Hátrány: Androidra csomagot készíteni macerás, legalábbis nekem úgy tűnik.

--
eutlantis

Köszi, erről a Kivy-ről most hallok először. Illetve másodszor, mert tegnap éjjel egy blogon már belebotlottam.

Hehh... miket találok :)
http://weblabor.hu/forumok/temak/112872

Közel hat éve kezdtem bele ugyanebbe, majd kukáztam a projektet. A wx-ről csak annyi maradt meg, hogy jobb kerülni.
Az okra nem emlékeztem. A jelek szerint érdemes elővenni, már nincs windows-om, így a windows support kérdése sem számít.

"A PySide2-őt én is néztem korábban, de elvesztettem iránta a bizalmamat, mert úgy tűnt, hogy nagyon lassan jut el egy kiforrott állapotba."

Úgy tűnik 2018-ban ez változni fog, mert lassan érkezni fog a hivatalos támogatás is. http://download.qt.io/snapshots/ci/pyside/5.9/latest/pyside2/
--
♙♘♗♖♕♔

( joelzimmer | 2018. 03. 17., szo – 10:06 )

Én most RPi-hoz hobbiból csináltam egy "okos" órát (idő,dátum,időjárás),de arra jutottam,hogy a pythont nem GUI-s programokhoz találták ki.

És akkor helyette mit?
Főleg, ha cél a multplatform?
Monot kihagynám, így a C# kiesik.
Rubynak is vannak buktatói, még kevésbé tűnik támogatottnak alatta a legtöbb GUI framework, mint python3 alatt.
C++ hát legalábbis necces és rengeteg dolgot kell magamnak megoldani, ami pl. Pythonban a nyelv része (pl. unicode stringek kezelése)

Ha beagyazott rendszerre kell (rpi..), akkor javat ne! Tapasztalat..

En tkintert hasznaltam froccsontogep hutes szabalyozasanak megjelenitesehez, de szurnyo a hasznalata. Igazabol nem talaltam azota se jol hasznalhato gui-s libet pythonhoz es szerencsem van, hogy altalaban csak automata vezerlest kell csinalnom es nem kell hci.

De kovetem a szalat, hatha valaki mond valami jot..

Ö... namost... nem értem a kérdést...
Épp ott akadt el a dolog, hogy a pyqt5 enyhén szólva hiányosan dokumentált. A linked egyébként mintha qt3-ról szólna, miközben már a 4-es sem támogatott ;)

Ja, most látom, hogy ez másik szál: a qt nem nyelv, itt meg onnan ered a "mit?", hogy a python nem annyira jó gui programozáshoz.

Erre akartam válaszolni, bár tényleg nem egyértelmű:
>"C++ hát legalábbis necces és rengeteg dolgot kell magamnak megoldani..."
Egyébként a fenti linkem a Qt 5.9 online telepítőhöz mutat. Szerintem egy próbát megérne. Nem kell megriadni a C++ -tól.
http://doc.qt.io/qt-5/qtcore-module.html

+1. Nemreg dobtuk ossze kollegaval egy pygtk-s kioszk-programot (szinten rpi-re, szinten ora, idojaras, webkamera-kepek, statusz infok). Es sikerult megallapitanunk hogy a py(gtk)-t sem erre talalták ki es/vagy a py(gtk) még erre sem alkalmas igazan: az ora ugrik, ha valamelyik webkamera-kep epp' kiesik akkor lehal az egesz (nem, nem dob exception-t), nem igazan reszponziv. Nyilvan meg lehet csinalni jol is, de akkor a *.py kb pont annyira lesz komplex mintha igazi programnyelvbe (pl C-be) irnad - amihez eredetileg is interface-eltek ezeket a GUI-kat meg az egyebeket...

Nincs, viszont pont az kellene bele hogy megoldodjanak ezek a problemak. Persze multiprocesszel is lehetne csinalni, es akkor nem lenne gond ha thread-eles gazos lenne. De mondom, igy mar annyira komplex, hogy akkor mar inkabb C vagy valami rendes cucc.

A pygtk elott pytk-t (tkinter-t) probaltuk, de az meg ennyire se volt jo. Par honap akadozas utan lecsereltuk gtk-ra. Ezutobbi stabilabbnak/egyszerubbnek tunt. De persze ez az egesz csak jatek volt nekunk, semmi explicit kritikus szerepe nincs, igy nem mentunk el annyira a reszletekbe. Oke, ha mission critical lett volna, akkor C-be csinaljuk es nem pythonba, persze.

Nincs annyira beleteve az internetbe, de el tudom kuldeni ha erdekel (forras csak azon az rpi-n van, ami meg csak egy 10.*.*.*-os ip-n erheto el, olyan gepekrol amik meg kelloen le vannak tuzfalazva). De feltehetoen jo peldaja a "minden programnyelvben lehet C programot irni"-ra ;) Mondjuk a python-os gtk binding az tenyleg 1:1 lekepezese a C-beli libgtk(2) API-nak, szoval ez tkp ebben az esetben inkabb tautologia ;]

> +1. Nemreg dobtuk ossze kollegaval egy pygtk-s kioszk-programot (szinten rpi-re, szinten ora, idojaras, webkamera-kepek, statusz infok)

En is csinaltam "kioskot". Az utolso dolog lenne, ahol desktop appot jelenitenek meg.

Sima webbongeszo fullscreen. Meg electronos appal se bajlodnek.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( endi123 v | 2018. 03. 17., szo – 13:17 )

PyGObject (Python3 + Gtk3)
Pár hónapos tapasztalatom van, ezalatt átvergődtem magam jópár buktatón.

A C -> Python binding 99 százalékos, tehát maradtak olyan C-s függvények, strukturák, amihez nincs meg a Python binding. Ennek oka, hogy az automatikus PyGObject binding generator nem működik bizonyos C-s megoldásokkal. Szerencsére ezek egyrészt ritkák, másrészt ha belefutsz, "kézzel" Python-ból ctypes-on keresztül eléred a C-s interface-ket.

Másik probléma lehet PyGObject binding esetén a memória foglalás és memoria lyukak. Nekem is volt vele problémám, emellett pl LinuxMint-en is van olyan alap GUI program (panel widget), aminek memóriafoglalása szép lassan, hetek alatt felhízik 0.5-1GB-osra. Szóval a binding ilyen szempontból sem tökéletes (erre találtam elismert bug ticket-eket).

Összességében tetszett, mert sok mindent a python helyből megoldott, amikkel gépközelibb nyelveken elszöszöltem volna. Kisebb utility-k, GUI frontendek írásához ajánlom.

+1 a PyGObject-re, mivel a PyChess is ebben készül :)
A többszálú programok írása is lehetséges, csak nagy odafigyelést igényel, és a Gtk3 hívásokat illik a fő szálban végrehajtani Glib.idle_add() segítségével. A PyChess-ben régebben ezt csináltuk, de a Python3-ra való átálláskor egyúttal ezektől is megszabadultunk, és átálltunk az asyncio használatára.

http://python-gtk-3-tutorial.readthedocs.io/en/latest/index.html
https://pygobject.readthedocs.io/en/latest/index.html#
https://lazka.github.io/pgi-docs/index.html

PyQt tutorial témában hirtelen ezt az oldalt találtam https://martinfitzpatrick.name/tag/pyqt/
--
♙♘♗♖♕♔

Ezt te nézted már: https://lazka.github.io/pgi-docs/index.html?
Úgy, hogy pythonhoz kerestél doksit?
Én valahogy nem látom a kapcsolatot a kettő közt.
Interface pl. nincs pythonban, virtuális metódusok?
Hogy derül ki ebből, hogy egy esemény nevét nem konstansként kell használni, hanem stringként? Egy példa a tutorialból:

win.connect("delete-event", Gtk.main_quit)

A "delete-event" úgy tűnik, a fenti doksiban konstansként szerepel, bár nem egyértelmű. Egyáltalán, a .connect metódust hol találom ebben a doksiban?
Szóval ez így, hogy csak pythonból használnám, C++ ismeretek nélkül... és nem találok jobbat. :(

"Ezt te nézted már: https://lazka.github.io/pgi-docs/index.html?
Úgy, hogy pythonhoz kerestél doksit?"

Igen, rendszeresen ezt használom.

"Én valahogy nem látom a kapcsolatot a kettő közt."

Nem tudom milyen kapcsolatot hiányolsz, ez egy "PyGObject API Reference".

"Interface pl. nincs pythonban, virtuális metódusok?
Hogy derül ki ebből, hogy egy esemény nevét nem konstansként kell használni, hanem stringként? Egy példa a tutorialból:

win.connect("delete-event", Gtk.main_quit)"

http://python-gtk-3-tutorial.readthedocs.io/en/latest/basics.html#signa…

"A "delete-event" úgy tűnik, a fenti doksiban konstansként szerepel, bár nem egyértelmű. Egyáltalán, a .connect metódust hol találom ebben a doksiban?"

https://lazka.github.io/pgi-docs/index.html#GObject-2.0/classes/Object…
--
♙♘♗♖♕♔

Basszus, el kell mennem, ne felejtsem el ezt...
Valmi link nagyon rossz helyre vitt (Signals felirata volt annak is)
Térjünk erre vissza, mert úgy fest, valamit nem veszek észre abban a dokumentációban, ami nekem nagyon hiányzik.

Update: asszem, mínusz egy rejtély... a noscriptet nem szereti az az oldal.

Na jó, ennek neki kell futnom még1x.
Mobilról nézegettem, a lapok teteje nagyon olyan volt, mintha valami C++ doksi lenne (pl. __init__ leírást nem láttam sehol, de new metódust igen, ami nem tűnt igazán pythonosnak)
Látok ott olyanokat, hogy interfaces, virtual methods, meg a bánat tudja még mi mindent, amik szintén nem kifejezetten pythonos dolgok amennyire a pythont ismerem.

Update:
Ez megnyugtató, annyira mégsem hülyültem el, csak kicsit keresni kellett, hogy merre járhattam korábban...
Erre mit lépsz?
https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/DrawingArea.html#Gtk…

A benne lévő példakód színtiszta C vagy C++. Köze nincs a pythonhoz. Nem véletlenül gondoltam, hogy valami nem kerek ezzel a dokumentációval.

"What is this?
A tool to create sphinx documentation for gi modules using python introspection.
pgidocgen.py create introspects the gi module, pulls in the gir docs and creates a sphinx environment.
pgidocgen.py build builds html docs using sphinx."

Szóval ez az egész API dokumentáció programmal, automatikusan generálódik. A példakódokat valószínűleg elég nehéz lenne automatikusan C-ből Python3-ba konvertálni. Ezért ezeket egyenként, kézzel kellene megírni, amihez ennek a Christoph Reiter gyereknek egymagában nem sok kedve van. Ebben egyébként egyet is értek vele. Az ilyen Python3-ra átírt példa programokat egyébként szívesen veszi a http://python-gtk-3-tutorial.readthedocs.io/en/latest/index.html karbantartója.
--
♙♘♗♖♕♔

Jó, ez a része annyira nem izgalmas, csak azért hoztam ide, hogy végsősoron nem hallucináció volt, hogy C-t láttam benne :)

Egyébként meg... https://hup.hu/node/158516#comment-2211935
Azt hiszem, mára eljutottam a tízéves szabadság okozta leépülésnek arra a szintjére, ahol már nem csak a közelítő vakság akadályoz a tanulásban. :(

( kantal | 2018. 03. 17., szo – 13:38 )

Az eddigi hozzászólások alapján úgy tűnik, hogy a "bindingekkel" (Qt,GTK+) sok a baj.
Ha jól tudom, akkor a Kivy nem "bindinges", hanem "natív" pythonos fejlesztés; nyilván használ külső könyvtárakat, de a saját koncepciója szerint.

--
eutlantis

( kantal | 2018. 03. 18., v – 10:39 )

Sok hozzászóló elégedetlen a Tkinterrel; megtudhatom konkrétan, hogy miért? (Nem kötözködni akarok.)
--
eutlantis

( STP | 2018. 03. 18., v – 11:41 )

Backend akármi, frontend HTML5 (böngésző)

( Balzamon | 2018. 03. 18., v – 16:32 )

Érdekelne, hogy van-e élő ember, aki rendszeresen készít GUI-s programokat python3-ban?
Ez azért túlzás. Inkább csak ismerkedem a programozással. Most cseréltem le a tkinter-t wxPythonra, igazából azért, mert ehhez van normális GUI tervező.
A feltételeidnek nagyjából megfelel. Hogy én miért választottam:
- most jelent meg a 4-s verzió, ami már hivatalos, és pip-pel is telepíthető. Python3 kompatibilis.
- van hozzá dokumentáció - igaz nem mind friss -
- https://www.wxpython.org/ - weboldal
- vannak könyvek, videók igaz csak a régebbi verziókhoz
- multiplatform
- szabadon felhasználható
- wxFormbuilder

( akusebi | 2018. 03. 18., v – 17:18 )

Én a PyQt-t használom szinte mindenhez amihez GUI-t csinálok. Egy ideje csak Python3-t használok, így a PyQt5 csomagot, régebben Python 2/PyQt4-et használtam. Kisebb nehézségeket leszámítva minden szépen működik Linux és Windows környezetben is. Az utóbbi időben még a QtQuick-et is kipróbáltam, az is működik.

A dokumentáció nem mindig érhető el Pythonhoz, de a C++ dokumentáció nekem általában szokott tudni segíteni.

Illetve a neten is van rengeteg példa.

PyQt5 engem azzal akasztott ki, hogy már a teljes "dokumentáció" egy linkhalmaz a Qt5 doksira. És van néhány dolog, amit nem lehet 1:1-ben átültetni C-re, ha jól emlékszem. Már a korábbi, 3-as v. 4-es is csak 20-30%-ot fedett le, a maradéknál kénytelen voltam a Qt leírást nézni, de ott még látszott a hajlandóság. Most meg... mint a csirke parasztosan: "ne B+!". Ha legalább közvetlen linkek lennének és nem kéne duplán kattogtatni az egeret...

( kantal | 2018. 03. 18., v – 20:36 )

Itt most minden 10$: https://www.packtpub.com/
Keresés után 1 db PyQt-es könyvet és három Tkinter-est találtam.
Nem tudom milyen minőségűek, adnak-e többet, mint a neten fellelhető doksik.

--
eutlantis

( uid_7086 | 2018. 03. 19., h – 14:47 )

Egyelőre orrhosszal nyert a GObject :)
Eredetileg wxPythont akartam, de az nincs benne az ubuntu 16.04 gyári repokban, csak pip3 segítségével lehetne felvarázsolni, de az most nem nyerő... (főleg azért, mert virtualenv alatt a telepítése csak egy nagy halom hibaüzenetet produkált :) - bár ez lehet, hogy csak azért volt, mert olvasás nélkül próbáltam ki a pip install wxPython-t)

> Eredendően innen jött a tkinter, mert az ott van minden python telepítésben.

Igazabol, ha csak nem mondok/csinalok hulyeseget, szerintem ez sem igaz igy teljesen.
Windowson pl. a Py3.6 telepito wizard egyik checkboxa az, hogy kerem-e a tkinter csomagot vagy sem (par hete telepitettem).

De... Hirtelen ket-ket proba Ubuntu 16.04-en:
Python2

Python 2.7.12 (default, Dec 4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import tkinter
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named tkinter

>>> import Tkinter
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 42, in
raise ImportError, str(msg) + ', please install the python-tk package'
ImportError: No module named _tkinter, please install the python-tk package
>>>

Python3

Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import tkinter
Traceback (most recent call last):
File "/usr/lib/python3.5/tkinter/__init__.py", line 36, in
import _tkinter
ImportError: No module named '_tkinter'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/tkinter/__init__.py", line 38, in
raise ImportError(str(msg) + ', please install the python3-tk package')
ImportError: No module named '_tkinter', please install the python3-tk package
>>>

>>> import Tkinter
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named 'Tkinter'
>>>

Hat ez bizony nincs itt (nem toroltem nem le, nincs venv-ben)

-------------------------
Roses are red
Violets are blue
Unexpected '}' on line 32

Itt már volt valami varázslat, régebben az volt a mondás, hogy a Tkinter a default, ha van GUI-d, akkor általában volt Tkinter is.

"The tkinter package (“Tk interface”) is the standard Python interface to the Tk GUI toolkit"

Windows-ra by default felment, sose kerestem, hogy ki lehet-e herélni.
A virtuális gépeimen, ahol nincs GUI, ott valóban nincs fent a python-tk, de a laptopra semmi ilyet nem raktam fel, mégis ott volt.

O.K., de ha használható programot akarok írni, akkor szükség lehet az egyszerű telepítésre, ott nem várhatom el, hogy a pycharm legyen az első telepített szoftver. :)
Nem akarok kötekedni, de ennek a mondatodnak semmi értelme. Legalábbis én nem értem, mire akarsz kilyukadni.

"PyCharm-ot használok, ott a beállításokban lehet keresni és telepíteni modulokat"

Odáig rendben van, hogy a pycharm segít telepíteni, esetleg még képes is rá, de ennél egyszerűbb módszernek jobban örülnék.
És ha a pip3 nem segít, ahogy esetemben a wxpythonnal elhasalt...

Bocs, de ez kb. olyan mint böngésző kiegészítőt telepíteni. Rákeresel -> kiválasztod -> telepíted. Ennél egyszerűbb szerintem nem is lehetne. Kivéve ha elhasal a telepítő.:)
Amíg nem jelent meg a 4-s sokkal nehezebb volt telepíteni. Valami .whl fájlokkal szenvedtem. Linuxra azt se tudom már, hogy raktam fel. Megváltás, hogy végre lehet pip-pel telepíteni.
A PyCharm is biztosan azt használja a háttérben, csak így nem kell parancssorban pötyögni.

Várj, te egyre a pycharm-ról beszélsz. Én meg azt próbálom magyarázni, hogy ha netán írok valami mások számára is hasznos toolt, akkor a potenciális felhasználóktól nem várhatom el, hogy rakják fel maguknak a pycharm új verzióját csak azért, mert az képes telepíteni a wxPythont, a pip3 meg nem. (Azóta se néztem meg, hogy mi baja volt, nem kizárt még mindig, hogy én rontottam el valamit)
Kár, hogy nincs benne a repoban, mert egyébként pont a wx állna legközelebb ahhoz, amit kényelmesnek tartok.

Szerintem tévedésben vagy. Kevered a fejlesztést és a felhasználást. Azaz a fejlesztéshez kellenek olyan apróságok mint: fejlesztői környezet, modulok stb. Ebből készül egy végtermék (program). Ez két különböző dolog. Nem ugyanaz kell a fejlesztéshez mint a felhasználáshoz. Linuxon nem értek a csomag/programkészítéshez - Windowson is csak 1x csináltam ilyet -, de ha csinálnék programot tuti mellécsomagolnék minden modult, hogy ne a felhasználónak kelljen bűvészkednie a telepítéssel. A millió függőséggel. Linuxon is vannak erre megoldások. Pl: snap, flatpack.
Tehát csak annyit akarok mondani, hogy én előbb inkább a program fejlesztésével foglalkoznék, ráérek később azon agyalni, hogy hogy lehet ebből a felhasználó számára könnyen telepíthető programot/csomagot csinálni.

Hát nem t'om... mivel nem komplex rendszerek felépítése a célom, csak apróbb kisegítő programokat akarok írni benne, telepítőt írni nem igazán áll szándékomban (kétszáz soros python script, meg ötszáz sor telepítő?)
Szeretnék olyasmiből építkezni, ami normálisan dokumentált, könnyen telepíthető és a függőségei kimerülnek egy pár elemből álló apt-get install-ban.
Na a wxpython sajnos nem ez a kategória. :(
Nem tudom, pycharm alatt fel tudnám-e rakni, most túrtam a netet a telepítési leírás után, amiből csak olyat találtam, ami python2-ről szól, illetve olyat, amiben volt egy kissé cinikus megjegyzés, hogy "hát minden konfig más, bogozd ki, hogy mi kellhet még a leírtakon túl!" - erősen szabad fordításban (https://wxpython.org/blog/2017-08-17-builds-for-linux-with-pip/ itt keress rá az OpenGL-re)

És tegyük hozzá, nem munkáról van szó - ott picit másképp állnék hozzá - hanem szórakozásból írt programokról.

Szeretnék olyasmiből építkezni, ami normálisan dokumentált, könnyen telepíthető és a függőségei kimerülnek egy pár elemből álló apt-get install-ban.
Bocs, de így kb. az awk marad, meg a konzolos szkript. Így nemcsak a GUI, de a Python sem a barátod, hiszen a Python egyik nagy előnye pont a rengeteg külső modul. Kizárt, hogy mindből van csomag.

Manjaro-ra szerintem már pip install wxpython-nal is felmegy. Majd kipróbálom. Nem értünk egyet, szerintem ha már csinálok valamit, csináljam rendesen.

Valószínűleg nálam is felmenne, ha lenne telepítve pár opengl-dev csomag...
Rengeteg dolog működik egyébként apt-ből telepített eszközökkel, főleg, ha beérem a 2-es pythonnal.
Abban viszont nem értek egyet, hogy csomagoljunk minden függőséget a saját cucc mellé, ahogy korábban írtad.

A 2-es Pythont-t nyugodtan felejtsd el. Egyrészt 2020-ban hivatalosan véget ér a támogatása, másrészt nagyon ritka már az, amit még nem portoltak 3-asra, vagy ne lenne helyette valami más, eleve 3-asban írt.

A csomagolás meg egy teljesen más téma. A különféle Linux-okra érdemes követni azok csomagolási szokásait, windows-ra meg csinálni valamilyen all-in-one telepítőt. Lásd pl.: https://github.com/pychess/pychess/releases
--
♙♘♗♖♕♔

Vicces:
$ apt-cache search python3 | grep rrd
$
Ubuntu 16.04.4
Igaz, a pip már jobb egy fokkal, ott van n+1 hasonló csomag.
Ráadásul amikor szükség lett volna rá, akkor akárhol kerestem, csak a 2-es változatot találtam. :(
(pip3 valószínűleg kimaradt akkor a keresésből)

Úgy tűnik, a törölt blog posztjaim egyikében anyáztam pár hete, hogy kb. minden második package, amit használnék, csak python2 alól érhető el.
Sajnos nem tudom, mi volt a másik, ami nagyon kellett volna.
Pedig lehet, hogy az is megvan pip alatt.

Abban viszont nem értek egyet, hogy csomagoljunk minden függőséget a saját cucc mellé, ahogy korábban írtad.
Nem pont ezt írtam. Inkább ezt:
Tehát csak annyit akarok mondani, hogy én előbb inkább a program fejlesztésével foglalkoznék, ráérek később azon agyalni, hogy hogy lehet ebből a felhasználó számára könnyen telepíthető programot/csomagot csinálni.
Arra céloztam, hogy ne az eszköz határozza meg a feladatot, hanem a feladat az eszközt. Tehát előbb legyen kész és jó a program, aztán utána lehet gondolkodni a csomagoláson. Az hogy én Windowson mellécsomagoltam minden függőséget egy fájlba, ezért olyan gépen is futott, amin a Python nem volt telepítve, az csak egy példa volt.

Ebben az a poén, hogy PyGObject csomagot egy darabot sem telepítettem. Fogalmam sincs, hogy került a gépemre, de fenn van. :)
Gyanítom, a Unity egyik alkatrésze vagy más GUIs cucc hozta magával függőségként.
Egy apt-get autoremove --simulate python3-gi elég érdekes listát ad az automatikusan eltávolítandó csomagokról. Kb. a fél rendszer. :)

Sejtettem :)
Bár... valamelyik monitorozó szoftvert pl. nem lehetett repoból telepíteni ubuntura sem, mert nem volt hajlandó működni.
Saját oldaláról letöltve működött.
Eclipse+pydev (hogy ontopic is legyen) detto.

A PyGObject csak azért volt furcsa, mert ezeknél nem vagyok hozzászokva, hogy linuxra maguktól felmásznak (konkrétan az, hogy bármely rendszer alkatrész 3-as pythont használ)

( uid_7086 | 2018. 03. 19., h – 17:46 )

Azért ez roppant szomorú.
Gyakorlatilag minden eddig megnézett cucc (PyQt5, PyGObject, Tkinter stb.) doksija a használhatatlan kategóriába tartozik, ha az ember nem tud C-t fejben pythonra fordítani...
Roppant zavaró, hogy az ember arra koncentrálna, hogy mit is csinál egy-egy alkotóeleme az adott csomagnak, ehelyett azon kell töprengeni, hogy akkor most mi is van az __init__ helyett és az egyes nyelvi elemeket hogyan forgassam át pythonra. (mondjuk C-nél még elmegy, de amikor képbe kerül az OOP, akkor a C++... hát nem mindig egyszerű)

Tkinter még rosszabb e tekintetben, mert ott meg a Tcl/tk-t kell megérteni és átültetni real-time :(

Najó, ezt itt, hogy úgy mondjam, benéztem, de rendesen.
A PyGObject ref.guide (API) mégiscsak python, csak helyenként kicsit furcsa szóhasználattal és nem árt az első ötven soron túl is körülnézni.

A tkinter-nél persze nem az van, mint a Qt esetében, mert ott a doksi egy része megvan pythonos formában, csak azok a triviális részleteket tartalmazzák. Amikor valahol mélyebbre kell túrni, akkor jön elő, hogy hát azt nézd meg a tcl/tk leírásában.

( uid_7086 | 2018. 03. 20., k – 12:09 )

PyGObjectet használva hogyan, pontosabban mivel lehet pontokat, vonalakat, esetleg görbéket rajzolni?
Ilyesmikre gondolok:
https://github.com/haa-zee/python3-sandbox/blob/master/probak/tkpro_can…
https://github.com/haa-zee/python3-sandbox/blob/master/probak/tkpro_can…

Létezik, hogy csak a cairo használatával?
Főleg a második a problémás egy rövidke keresést követően, az animációs jellege miatt.

( uid_7086 | 2018. 03. 20., k – 21:35 )

PyGObject Gtk - ha kimarad a
win=Gtk.Window() után a win.connect("delete-event", Gtk.main_quit), akkor nem lehet normál úton lelőni a programot, mert még a Ctrl-C-t is lenyeli.
kill kell neki, hogy leálljon. :(
Vajon ez normális vagy már megint nem vettem észre valamit?

Normális, vagy inkább "normális"
https://bugzilla.gnome.org/show_bug.cgi?id=622084
Elvileg javították 2017 végén, az idén megjelenő linux-ok már tartalmazzák a javítást.

workarounds (2018 előtti rendszerekhez):
https://stackoverflow.com/questions/26388088/python-gtk-signal-handler-…
https://stackoverflow.com/questions/16410852/keyboard-interrupt-with-wi…

( uid_7086 | 2018. 03. 21., sze – 23:55 )

Sajnálom, hogy nem blogba írtam ezt a témát.
Most nyugodt lélekkel törölném.
Elkurvult ez az IT világ, de nagyon. Főleg dokumentálás terén. Lenne egy kellemesnek mondható nyelv, a python, már napok óta azon nyűglődök, hogy milyen GUI-t próbáljak alaposabban megismerni, hogy ne koppanjak túl nagyot vele, könnyen és gyorsan használatba vehessem.

Próblnék olyan triviális szarokat megtalálni, hogy hogyan kell a PyGObject Gtk moduljának használatával egy szöveges beviteli mező tartalmát ellenőrizni, hogy mondjuk ha valahol IP címet várok, akkor akármilyen krixkraxot ne fogadjon el. Biztosan bennem van a hiba, de konkrétan erre vonatkozó példát nem találok.
Szeretnék vonalakat rajzolni. Semmi extra, csak x időközönként egy-egy függőleges vonal, illetve ha ez ronda, akkor grafikon jelleggel, egy-egy pontot kirakni és az újat az előzővel összekötni egyetlen vonallal. Ilyet se találok. Van szó cairo-ról valami statisztikai modulról meg még a bánat tudja miről. De hogy (ex has kitalálok neveket) lenne egy Gtk.Canvas(), amire lehetne rajzolni a saját metódusaival, ahogy pl. a Tkinter is tudja, meg a Qt QPaint-je... na olyat még véletlenül sem találok.
És ez még csak a kezdet.

Nem embernek való ez az egész...

Az elsőhöz:
https://gist.github.com/gbtami/a1dbbffac2ee8e1aed0c28112c9c279e
https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Editable.html#signals

A másodikhoz:
https://github.com/GNOME/pygobject/blob/master/examples/cairo-demo.py
https://pycairo.readthedocs.io/en/latest/
--
♙♘♗♖♕♔

Köszi szépen, de szerintem jobban jársz, ha nem foglalkozol velem. Csak a saját tehetetlenségemen dühöngök.
Basszus... anno orosz nyelvű doksikból ki tudtam bányászni a lényeges infókat, pedig alig tudtam valamit oroszul, most meg az angolokkal sem boldogulok, pedig az angol sokkal jobban megy, mint anno az orosz.

Ráadás, hogy az a nyomorult google egyre kevésbé ad hasznos, releváns találatokat.

Azt hittem pár hete, hogy pythonban összedobni egy sima űrlapot, öt perces feladvány. Ehhez képest még mindig ott tartok ahol... :(

Ui: a másodikkal épp az a nagy bajom, hogy cairo nélkül mintha esélytelen lenne...

+1 megtanulandó framework, ami eddigi olvasmányaim alapján mintha nem illeszkedne igazán a pygobject saját rendszerébe.
Annyi maradt meg, hogy valamit átvettek belőle, de azzal meg már nem emlékszem, milyen problémák vannak.

Valahogy arra számítottam az évekkel ezelőtti Qt-s próbálkozásaim alapján, hogy "házon belül" megoldottak mindent.
Hogy van egy osztály, ami egy rajztábla, pont, vonal, görbe, esetleg 2d-s alakzatok rajzolására alkalmas eszközökkel, ami a gobjects vagy még inkább a gtk osztályaiból épül fel.

Hogy fogok egy Frame/Window ojjektumot, beledobok egy layout managert, abba a saját kis szarjaimat és működik a form, mindenféle mágia nélkül, nem kell (ha nem akarok) signalokkal foglalkozni, hogy két sorban elintézhető pl. egy scrollozott grafikon (lásd gui-s monitor programokon a cpu használat grafikonja), mert egy nem látható rajzlapra kirajzolom az aktuális állapotot, aztán egyben lecserélem, amitől olyan, mintha mozogna, hogy (ez ugyan nem a rajzolós dolog), egy beviteli mező tartalmának a validációja kimerül egy validate=függvény paraméterben, ahogy pl. a tkinterben, csak ott kissé... khm... hiányos pont ez a dokumentáció... (vagy legalábbis én nem találtam, a blogban ahol leírták, hogy hogy műxik, ott a szerző is azt írta, hogy nem túl bőbeszédű a doksi e téren) stb.
Szóval nem kicsit frusztráló ez az egész.
Főleg az, hogy ezekhez az újabb vackokhoz, legyen az pygobject pygtk helyett, vagy qt5 qt4 helyett, alig találok hasznos infót. A legtöbbször nézzem meg a C-s leírást, használjam a korábbi verzióét, csak legyek tekintettel a nem kevés eltérésre stb.
Elhiszem, hogy ha valaki benne élt és követte a változásokat, annak ez nem okoz gondot, de így nulláról... hát hosszú távú hobbinak biztosan nem fog megmaradni.