Názory k článku Vztah PyGTK a GTK

No já nevím, to vysvětlení se mi moc nelíbí. Programuju už dlouho a štítky (labels?) jsem potkal tak maximálně při třídění pošty.

Prostě GTK je knihovna v C a poskytuje céčkovské, jemně objektové API. No a PyGTK je jen lehké zapouzdření (binding) tohoto nízkoúrovňového API. Programování v PyGTK je vlastně skriptování GTK a je potřeba mít na mysli, že si hraju s objektama ala C.

A to že properties z GTK nejsou v Pythonu prezentovány jako Pythoní properties, to je prostě designové rozhodnutí. Ono ty properties taky v Pythonu nejsou odjakživa.

Velmi srozumitelně, stručně a dobře psaný seriál. Od samého začátku jsem si ho oblíbil a proto chci za něj autorovi poděkovat a řict "jen tak dál":-)

Tak tento dil se mi tedy opravdu nelibi. Razit nestandardni pojem stitek misto reference nebo odkaz na objekt je velmi nestastne rozhodnuti, ktery zkusene programatory rozcili a z nezkusenych udela hlupaky a prinese jim zbytecne zmateni. Tenhle dil by bylo vhodne prislusne opravit. Autor sam by si mel ujasnit, ze python ma promenne, ktere nenesou data ale pouze odkazy na datove objekty. Tim by se vyhnul krkolomnym nesrozumitelnym vetam typu:

Při dalším průchodu vzniká nové tlačítko voláním gtk.Button() a jeho štítkem (jeho návratem) je přepsán původní obsah-štítek v tlacitko...

A mohl by srozumitelne napsat: Pri dalsim pruchodu volanim gtk.Button() vznika novy objekt tlacitko a odkaz na nej je prirazen do promenne tlacitko (mimochodem, z didaktickych duvodu nestastne zvoleny nazev promenne)...

Dale, GTK+ neni knihovna ale sada knihoven. A knihovna gtk nic nekresli, knihovna gtk jsou pripravene widgety. Na vykreslovani se pouzivaji nize postavene knihovny. Viz treba zde: http://wraith.iglu.cz/python/tech-gui-toolkity-gtk.php

To by fungovalo a skvěle..., kdyby textovy_buffer byl pythoní objekt. Ale on není, textovy_buffer je jen štítek a ona žádaná property sice existuje, ale v GTK+, ne v Pythonu a já si pro ni přímo prostě nesáhnu

Autor sam nechape, jak to vlastne funguje. textovy_buffer neni stitek, je to promenna, ktery se odkazuje na pythoni objekt, tedy de facto to je pythonni objekt. Ze si na to autor nesahne neni proto, ze se jedna o odkaz, ale proto, ze pygtk tuto funkcionalitu, z duvodu rozhodnuti svych programatoru, neposkytuje. Autor by si tedy nemel plest promenne, odkazy, pythonni objekty, C objekty a jeste tomu davat zmatecne nazvy jako stitky a transfery.

Dle titulku článku "Vztah PyGTK a GTK" jsem očekával, že si rozšířím obzory a autor se rozepíše například o .defs souborech, které propojují dynamický typový systém knihovny glib s typovým systémem pythonu. Místo toho mě čekala studená sprcha v podobě nepřesností, bludů a zmatené terminologie, které svědčí o tom, že autor není v problematice příliš zběhlý.

Implemented Interfaces Tady si významem nejsem jist. Rozhodně to budu muset někdy důkladněji prozkoumat. Ono gtk.Buildable zavání gladem.

Glib a potažmo GObject poskytují plnohodnotný dynamický objektový systém pro jazyk c včetně rozhraní, tak jak je známe z objektových jazyků. Položka Implemented Interfaces tedy říká, jaká rozhraní daná třída implementuje - pro pygtk má pouze informativní charakter.

To mě vyloženě láká k (textový prohlížeč v předchozím díle) přečtení print textovy_buffer.text. To by fungovalo a skvěle..., kdyby textovy_buffer byl pythoní objekt. Ale on není, textovy_buffer je jen štítek a ona žádaná property sice existuje, ale v GTK+, ne v Pythonu a já si pro ni přímo prostě nesáhnu.

Tahle část nemá ani hlavu ani patu. Když zkusím print textovy_buffer.text samozřejmě dostanu AttributeError, ale rozhodně ne z výše popsaných důvodů. Prostě tam není. Ale již od verze pygtk 2.8 mám k property tříd odvozených z GObject přístup, viz http://live.gnome.org/PyGTK/WhatsNew28 . Proto stačí jednoduše napsat print textovy_buffer.props.text a jsme doma.

První díly články vypadali nadějně, ovšem tento mě zklamal. Poprosil bych autora, aby si do příštího dílu doplnil znalosti a budu se těšit na další pokračování.

Nové pojmenování starých věcí je sice nešťastné, ale při použití normální terminologie by toto byla krásná kapitola pro pochopení objektů.
To sice neodpovídá nadpisu, ale svoji roli to má.
Kdybych chtěl někomu vysvětlovat proč vůbec máme v programování nějaké objekty (kdysi mi přišlo, že pouze znesnadňují snadné věci), tak bych se o to snažil pomocí argumentů tohoto článku.
Takže se nestyďte moc, píšete docela hezky.