Python a PyQt - 2 (podmínky, cykly, tlačítka) (diskuse)

[pm]

Zapomněl jste uvést, že for má taky else.

[Ladislav Vaiz]

Jak to v současné době vypadá s kompatibilitou jednotlivých verzí Qt na úrovni zdrojáků? Pokrývá je nějak PyQt nebo je to jen wrapper k metodám?

Právě nekompatibilita mezi Qt 1->2 (a myslím že i 2->3), se kterou jsem se setkal při pokusech o portování aplikací, mě od Qt odrazuje. Nechce se mi dělat aplikaci, kterou budu muset za rok přepsat, protože nové verze Qt se objevují dost často. Změnilo se v tomto směru něco?

[Robert Krátký]

Aniž bych chtěl vyvolat flame, tak si dovolím podotknout, že např. GTK+ 1 a 2 také nejsou kompatibilní. Jinými slovy, velké změny provází nekompatibilita dost často. Nejsem sice programátor, ale připadá mi, že Trolltech to velmi usnadňuje.

[xyz]

GTK1 vzniklo jen tak mimochodem pro potřeby Gimpu. Když si ho vzalo do parády GNOME, zjistilo se, že je potřeba udělat zásadní změny, třeba podpora Unicode a podobně. Předělal se tedy i celý koncept a ten je tak dobrý a robustní, že od té doby nebylo potřeba v GTK dělat nekompatibilní změny. Poukazovat na to s nekoncepčností Qt, které chrlí jednu major verzi za druhou se mi nezdá vhodné.

[Michal Vyskočil]

PyQt supports Qt versions 1.43 to 3.3.5 and Python versions 1.5 to 2.4.2. Note that PyQt does not yet support Qt v4.

Ale PyQt4 už bude podporovat pouze Qt4.

[razor]

No když už se pouštíte do syntaxe pythonu, tak mezer na odsazení bloku nemusí být v rámci celého kódu stejný počet. Stejný počet musí být pouze na jedné úrovni vnoření. Příklad:

def foo():
_print 'a'
_for i in range(10):
_____________print 'b'
_____________print 'c'

Nicméně takhle dělat je to IMHO blbost. Ale lze.

[Marek Bernát]

Robiť layouty ručne je určite zaujímavé, ale nebolo by na škodu povedať čitateľom, že takto sa to proste nerobí. Aspoň zmienku o QtDesignerovi by som uvítal. Inak hrozí, že niekto začne manuálne editovať layouty (veľa začiatočníkov sa venuje práve takýmto blbostičkám, nevediac o tom, že je to strata času).

Časť o pythone sa mi celkom páči. Je dosť svižná a vyzerá to, že ste nezabudli na nič podstatné.

[Sodalite]

S QT Designerem se dá programovat i vPythonu? Vždycky, když jsem to zkoušel otevřít, tak na mě vyskočily nějaké informace o C/C++, lekl jsem se a zase jsem to zavřel. Neprogramuju profesionálně, spíš jen tak pro radost nějakou maličkou aplikaci, ale tohle by se mi hodilo. Kde se můžu dozvědet víc?

[Marek Bernát]

Samozrejme.

QtDesigner ukladá layout do xml .ui súborov. Tie môžete potom skompilovať pomocou pyuic.

Pre podrobnejšie info navštívte stránku pyqt. A google je tiež váš kamarát

[Michal Vyskočil]

Qt designer vytvoří .ui soubor, který se v Pythonu načte pomocí QWidgetFactory. Nějak takto

class UserInterface(QMainWindow):
  def __init__(self):
    QMainWindow.__init__(self)
    self.win = QWidgetFactory.create("layout.ui")

  def show(self):
    self.win.show()


def main(argv):
  app = QApplication(sys.argv)
  ui = UserInterface()
  app.setMainWidget(ui)

  app.connect(app, SIGNAL("lastWindowClosed()"),
              app, SLOT("quit()"))
  ui.show()
  ret = app.exec_loop()
  sys.exit(ret)

[Marek Bernát]

Ja poznám len pyuic, ale toto vyzerá krajšie.

Nemáte aj nejaké porovnanie o týchto dvoch prístupoch? Na nete som toho veľa nenašiel. Napríklad nie je takéto dynamické loadovanie pomalšie? A poskytujú oba spôsoby rovnako dobrú funkcionalitu?

[Michal Vyskočil]

Porovnání nemám. Je pravděpodobné, že dynamické nahrávání layoutu bude pomalejší, ale netroufám si říct o kolik, protože zase takový znalec Qt a PyQt nejsem. Funkčně by měly být oba dva způsoby stejné.

[Drlik Zbynek]

Skousim pouzivat QWidgetFactory ale nevim jak je to jestli to spoji signali a sloty a taky nevim udelat aby to fungovalo se subclasama. Uvedu muj priklad.
hlavni soubor:
import sys
import sip
from qt import *
from mainformsub import *

def main(args):
app=QApplication(args)
mainformapp=mainformsub()
mainformapp.show()
app.connect(app, SIGNAL("lastWindowClosed()"), app, SLOT("quit()"))
app.exec_loop()

if __name__=="__main__":
main(sys.argv)

cast z mainformsub.py
from qt import *
from qtui import *
#from mainform import mainform
from pysqlite2 import dbapi2 as sqlite
import os, sys, sha
import fmlibcz
from progressformsub import *
from printformsub import *

class mainform(QMainWindow):
def __init__(self,parent = None,name = None,fl = 0):
QMainWindow.__init__(self,parent,name,fl)
self.win = QWidgetFactory.create("mainform.ui")
def show(self):
self.win.show()

class mainformsub(mainform):

def __init__(self,parent = None,name = None,fl = 0):
mainform.__init__(self,parent,name,fl)
#optimalizacia velkosti okna

self.spolu_tl.setMinimumWidth(self.zoznam_listView.columnWidth(0)+self.zoznam_listView.columnWidth(1)-6)

self.spolu_lv.setMinimumHeight(self.spolu_lv.header().height()+QListViewItem(self.spolu_lv).height() + 2)
self.zoznam_listView.setMinimumHeight(self.zoznam_listView.header().height()+QListViewItem(self.zoznam_listView).height()*3 +2)
self.adjustSize()

vypisuje mi
Traceback (most recent call last):
File "fm3000cz_paska.py", line 14, in ?
main(sys.argv)
File "fm3000cz_paska.py", line 8, in main
mainform=mainformsub()
File
"/home/denix/server/devel/python/fm3000cz_paska/mainformsub.py", line 25, in __init__
self.spolu_tl.setMinimumWidth(self.zoznam_listView.columnWidth(0)+self.zoznam_listView.columnWidth(1)-6)
AttributeError: spolu_tl

[nardew]

a prostredie eric3 ste skusali? je priamo pre PyQt

[honza]

Robiť layouty ručne je určite zaujímavé, ale nebolo by na škodu povedať čitateľom, že takto sa to proste nerobí

Proc se deti uci ve skole nasobilku - vzdyt takhle se to nedela, vezme se na to prece kalkulacka.

Mam takove podezreni, ze graficka prostredi zatemnuji lidem mozek, vubec pak jiz nedokazi normalne uvazovat a vse co neni klikaci je jaksi k nicemu ...

[Marek Bernát]

O výchovnom procese sa baviť nejdem, nie som kvalifikovaný pedagóg.

Ale toto je úplne iný prípad. Skúšali ste už kresliť obrázok v GIMPe a potom ručne z konzoly pomocou príkazov na tvorbu grafických príkazov? Čo je podľa vás prirodzenejšie?

Rovnako je to s designovaním layoutu. Nejde o nič viac ako o nastavenie polohy jednotlivých elementov a to sa IMHO efektívne manuálne robiť nedá – musím _vidieť_ čo kam dávam.

Ja mám z vášho príspevku pocit, že vám zasa zatemnila mozog antigrafická mánia a výsledok je rovnaký ako pri prografickej: odpor k vysoko efektívnym nástrojom. Či už CLI, alebo GUI.

[Marek Bernát]

s/grafických príkazov/grafických primitív/

[Petr Mach]

Opět nesouhlasím, malování v Gimpu není to samé jako programování GUI aplikací. Navíc když budu mít úkol stejně upravit 10 000 obrázků, třeba je zmenšit na určitou velikost, udělám to radší příkazem, než abych to dělal ručně v Gimpu. Tady vidíte, jak váš příměr kulhá. Když mi jde o kvalitu, obrázek zmenším ručně v Gimpu, kdežto GUI neudělám v klikátku, nýbrž ho taky ručně naprogramuju. V obou případech tak mám větší možnosti a lepší kontrolu nad výsedkem.

[Marek Bernát]

Hovoríte o niečom celkom inom. Samozrejme, že pri automatizácii niečoho napíšete skript, to dá rozum. Ale ak chcete namaľovať povedzme nejaké zviera, tak to už automaticky nespravíte.

Rovnako nespravíte automaticky pekný design. Od čoho by potom boli designéri, že áno.

Samozrejme uznávam generovanie widgetov. Napríklad chcem mať desať buttonov pod sebou. Ja však vidím optimálny prístup v navrhnutí základného layoutu v QtDesignerovi a potom dopísaní kódu pre vytvorenie 10 takých buttonov, ktoré som si navrhol.

Ale ako umiestnite tie widgety ručne? To si tipnete rozmery a polohu, spustíte program, odmeriate, že ten button vpravo hore treba posunúť o 8px vľavo, prepíšete kód, spustíte program, ...

See what I mean?

[Petr Mach]

Ne, nehovořím o něčem jiném, hovořím o tom, že naklikaní GUI je svou podstatou omezující a že není pravda vaše tvrzení, že se to jinak nedělá. Dělat to ručně je ve skutečnosti ve všech směrech, s výjimkou pohodlnosti, lepší, protože jeho tvorbu má člověk víc pod kontrolou, ale o tom jsem už psal.

Ale ako umiestnite tie widgety ručne? To si tipnete rozmery a polohu, spustíte program, odmeriate, že ten button vpravo hore treba posunúť o 8px vľavo, prepíšete kód, spustíte program, ...

Ne, takto hloupě to dělají právě jen klikači. Já použiju dynamický layout aplikace. Konkrétní rozměry zadávám pouze u mezer mezi prvky. Mě vůbec nezajímá např. velikost tlačítka. Ani mě zajímat nemůže, protože potřebná velikost je lokalizace od lokalizace jiná.

[Marek Bernát]

Uznávam, že som napísal hlúposť, že inak sa to nerobí. Mal som napísať, že je to jeden zo spôsobov.

Ale nemáte pravdu, že tak to robia klikači. Klikači sú praveže takej potreby zbavený tým, že majú svoj grafický designovací nástroj (GDN). Jediné, čo klikači v GDN nemôžu, je svojvoľne meniť chovanie aplikácie. Taká flexibilita, ako ste správne podotkli, sa dá dosiahnuť len ručne. Ja som však nenaznačoval (aspoň nie zámerne), že k tomu je GDN určený.

Ale nechápem, čo máte na mysli pod "dynamickým layoutom aplikácie". Ten sa odkiaľ vezme? To je nejaká čierna skrinka, ktorá občas umiestni tlačítka napravo od testboxov, inokedy pod textareu, všetko správne odsadí, nastaví veľkosť všetkým elementom a tak? Bol by som rád keby ste mi skutočne vysvetlili, že ako vy navrhujete design layoutu.

Btw, veľkosť tlačidiel vás v konkrétnych prípadoch môže zaujímať. Ale na tom nezáleží, pretože QtDesigner má viacero možných nastavení policy pre všetky elementy. To znamená, či sa majú resizovať, ak áno, tak len zľava, prípadne zhora a podobne.

Proste sa mi zdá, že ten nástroj dosť podceňujete. Skúšali ste s ním vôbec niekedy robiť?

[Petr Mach]

Robiť layouty ručne je určite zaujímavé, ale nebolo by na škodu povedať čitateľom, že takto sa to proste nerobí.

Tak s tím zásadně nesouhlasím. Nejen že se to dělá, ale považuji to osobně dokonce za lepší přístup. Mohu takto totiž využít výhod OOP a ze základních GUI primitiv (widgetů) odvozovat (dědičností) vlastní specializované či optimalizované pro mé účely. Mohu a měl bych tak vytvářet i vlastní pseudowidgety sestavené z těch primitiv a lze i vytvořit vlastní nové widgety.

Není to sice vždy tak pohodlné, jako to naklikat, ale zato je to mnohem flexibilnější. To co vy dokážete naklikat já ručně dokážu udělat taky, ale ne vše co ja dovedu udělat ručně vy dokážete naklikat. Kdo se tohle naučí, bude dělat čistší a konzistentnější programy, a bude moci GUI obdařit vlastní logikou. Každý náročnější program si zaslouží tento přístup.

[Marek Bernát]

Hovoríte o niečom inom ako ja. Mne išlo o design layoutu. Design dosť dobre bez grafických nástrojov robiť nejde. TeX je svetlá výnimka, ale to je úplne iný prípad ako designovanie GUI.

A v QtDesignerovi ide hlavne o design, teda veľkost a polohu widgetov. Tieto informácie si ručne z prsta nevycucáte. Musíte vidieť, čo kam chcete dať. A potom keď vytvoríte tie vlastné elementy, tak ich znova bude treba premyslene umiestniť a toto ručne opať nedosiahnete.

Ja netvrdím, že budem programovať v QtDesignerovi – k tomu nie je určený. Ale rozhodne je určený (a vynikajúci) na designovanie layoutov.

Navyše .ui súbory sa pomerne priamočiaro dajú skompilovať do pythonovského kódu, takže dostanete kostru widgetu a ten si potom už doplníte vlastným kódom ako chcete.

[Petr Mach]

Hovoríte o niečom inom ako ja. Mne išlo o design layoutu. Design dosť dobre bez grafických nástrojov robiť nejde.

Já také mluvím o tvorbě GUI aplikace. GUI bez grafických nástojů jde navrhnout! A dokonce jde navrhnout velmi dobře, grafické designery přináší velké omezení.

A v QtDesignerovi ide hlavne o design, teda veľkost a polohu widgetov. Tieto informácie si ručne z prsta nevycucáte. Musíte vidieť, čo kam chcete dať. A potom keď vytvoríte tie vlastné elementy, tak ich znova bude treba premyslene umiestniť a toto ručne opať nedosiahnete.

Jste zcela mimo, já GUI navrhuji ručně a to jak v tom TeXu, tak u webových stránek, tak webových aplikací tak aplikací v Pythonu. Ve všech zmíněných případech máte při ruční tvorbě více možností a kontroly nad dílem a ve všech případech lze dosáhnout mnohem lepších výsledků. Ale musí se to umět, což je asi váš problém.

[Marek Bernát]

Ako ste prišli k záveru, že neviem pracovať inak, ako s GUI ? Urážať ma nemusíte, snáď som vám nič zlé nespravil

Napríklad LaTeX a HTML píšem ručne a pokiaľ možno podľa všetkých štandardov.

Ručný design má oproti tomu grafickému svoje výhody a nevýhody. Podľa mňa v prípade Qt je tých nevýhod oveľa viac.

Ale inak sa ospravedlňujem za to, že som povedal, že inak sa to nerobí. To bola naozaj hlúpa veta a ľutujem, že som ju povedal.

[Kyosuke]

Jestli to nebude tím Qt. Jak já to vidím, FOX a Gtk+ jsou pro ruční návrh víc user-friendly.

[Kyosuke]

Mimochodem, třeba takové Adobe - mám pocit, že zdroje pro Adama a Evu sido aplikací píšou prostě ručně, mrkněte se na ty jejich knihovny... (http://opensource.adobe.com)

[Marek Bernát]

A ešte som zabudol doplniť jeden dosť podstatný argument k tej väčšej flexibilite: prečo neprogramujete v assembleri? Máte oveľa väčšiu kontrolu nad systémovými prostriedkami. Aha, počujem niečo o tom, že je to zdĺhavé a nepraktické. Pravda, presne to si myslím o ručnom designe layoutov

Inak, nič v zlom. Stále existujú ľudia, ktorí sa nedokázali vzdať programovania v asm a možno sú v tom aj efektívnejší ako ja, ktorý programujem vo vyšších jazykoch. Prečo nie. Ich život, ich voľba.

Berte toto trochu s nadsázkou, chcel som len poukázať na analógiu.

Btw, qtdesignéra používa aj dosť programátorov z KDE. Ak si myslíte, že sú to všetko lamy, ktoré vedia len klikať, tak už nemám viac argumentov.

[honza]

Btw, qtdesignéra používa aj dosť programátorov z KDE. Ak si myslíte, že sú to všetko lamy, ktoré vedia len klikať, tak už nemám viac argumentov.

Na takovou argumentaci se da rici vzdy jen nasledujici:

"lidi zerte fekalie, miliardy much se prece nemohou mylit!"

Dotknul jsem se pouze toho povrchniho ve vasem prispevku, protoze je to skutecne ztrata casu o te technicke problematice s vami diskutovat. Ale mozna, ze by nam k tomu disputu neco mohl rici nas "abclinuxu-ovsky" psychoanalytik pan Jilek?

[Marek Bernát]

Z vás by bol vynikajúci demagóg (vlastne už je). Z troch mojich príspevkov a záplavy argumentov si vyberiete dve vety, ktoré nie sú pointou a potom na ne reagujete hláškou, ktorá je úplne mimo. To akože porovnávate vývojarov z KDE s muchami, pochopil som to správne?

Snáď máte trochu súdnosti a viete rozlišovať medzi miliónmi obyčajných použivateľov a ľuďmi, ktorý vytvorili jeden z najpopulárnejších desktop managerov.

A diskutovať o tejto problematike vás samozrejme nikto nenúti. Ak nepoužívate QtDesignéra, je to vaša vec. Ja som len upozornil na to, že väčšina vývojárov ho používa a povedal som aj prečo.

[Petr Mach]

väčšej flexibilite: prečo neprogramujete v assembleri? Máte oveľa väčšiu kontrolu nad systémovými prostriedkami

Ano, mám například větší kontrolu nad systémovými prostředky, ale zase například je takový program omezen na jednu architekturu procesoru. Takže to těžko můžete nazývat flexibilnější. Krom toho asembler není vhodný na psaní větších projektů, nemá pro to podpůrné prostředky, je tedy v mnohém omezující, stejně jako je omezující návrh GUI v nějakém designeru. Proto nepoužívám ani jeden.

Mně nevadí, že někdo používá designer, je to každého věc v čem a jak programuje. Já jen vyvracím vaše hloupé tvrzení, že ručně se layouty nedělají a že je to ztráta času. Ručně se GUI navrhuje a má to řadu výhod.

Btw, qtdesignéra používa aj dosť programátorov z KDE. Ak si myslíte, že sú to všetko lamy, ktoré vedia len klikať, tak už nemám viac argumentov.

Podstrkujete mi něco, co jsem neřekl a pak se nad tím pohoršujete. To je podlý způsob diskuze. Lidi k němu obvykle sahají, když nemají jiné argumenty.

[Marek Bernát]

Toto boli moje hlúpe "argumenty" v zápale mojej obhajoby. Samozrejme som pochopil, aké sú prázdne hneď ako som sa nad nimi trochu zamyslel

Inak, ďakujem za diskusiu. Keď nič iné, tak aspoň nabudúce sa viacej zamyslím, že čo vlastne píšem. Som vám vďačný, že ste mi pomohli odhaliť tento môj "problémik" a snáď sa mi ho nejako postupne podarí vyriešiť

[jean]

Kdyz to srovnam s Ruby/GTK, ktere pouzivam, tak mi z tech prikladu PyQT prijde o dost horsi. "Hello Word" v Ruby/GTK:

require 'gtk2'
Gtk.init

button = Gtk::Button.new("Hello World")
button.signal_connect("clicked") { puts "Hello World" }

window = Gtk::Window.new
window.signal_connect("destroy") { Gtk.main_quit }
window.add(button)
window.show_all

Gtk.main

[Marek Bernát]

Je to prakticky rovnaké: inklúdneš knižnicu, vytvoríš widgety, spustíš program. Možno je to o trochu elegantnejšie kvôli blokom, ale to je skôr vec vkusu.

[jean]

Mozna trochu? Vec vkusu? Tohle nekomu pripada elegantni?:

app.connect(app, SIGNAL("lastWindowClosed()"), app, SLOT("quit()"))

Nezdaji se mi tam jeste nejmene tri dalsi veci, ktere jsou opravdu minoritni. Co me ale doopravdy dostalo je importovani celeho qt a pojmenovavani trid jako "QTyp". Kdyz se qt neimportuje, tak je to napr. qt.QVBoxLayout? K cemu v tom pythonu proboha ty namespaces vubec mate, kdyz potom delate takovehle prasarny? Dival jsem se, jestli to je pythonovska tendence likvidovat namespaces, ale asi ne, protoze v PyGTK je to udelany tak, jak by clovek ocekaval:

window.add(gtk.Button("Hello World"))

o 100% lepsi nez tahle katastrofa:

win.button=QPushButton(win,"Hello")
win.button.setText("Hello World")

Navic to vypada, ze je to doslovna kopie C++ interface, akorat se to pise v Pythonu. K cemu pak psat v Pythonu, kdyz v nem pisu to same jako v C++? Neni lepsi to pak uz delat rovnou v C++? No nic, alespon me ten clanek utvrdil v tom, ze jsem si zvolil spravnej jazyk i toolkit ;).

[Marek Bernát]

Jazyky aj toolkity sú si zhruba ekvivalentné. Ak si si už nejaký vybral, tak si spravil dobre, pretože nemáš čo získať prejdením na iný. Ale zároveň by si PyQT nemal podceňovať. Ako hovorím, možno je trochu menej elegantné, ale stále je veľmi dobre použiteľné.

V PyQT samozrejme zostali niektoré veci z C++. Ale ja som písal Qt najprv v C++ a tam je connect(ob1, SIGNAL, ob2, SLOT) prakticky to najlepšie, čo sa dá vymyslieť a mne to pripadá veľmi elegantné. Preto ani v pythone s tým nemám problém, aj keď v ňom by sa vďaka jeho dynamickej náture dalo vymyslieť aj niečo lepšie. Ale bloky zatiaľ nemá

To s tým importovaním samozrejme ide, ako len chceš. To že autor tohoto článku zvolil tento štýl je jeho vec. Snáď len mohol povedať, že to ide aj inak.

A pozostatok z C++ sa samozrejme týka aj toho setTextu. Ale python má aj atribúty rovnako ako Ruby, takže snáď v budúcnosti sa dočkáme...

[pm]

Ano, GTK je lepší toolkit než Qt, v pythonu se váš příklad napíše takto:

import gtk

def hClicked(button):
    print "Hello World"

button = gtk.Button("Hello World")
button.connect("clicked", hClicked)

window = gtk.Window()
window.connect("destroy", gtk.main_quit)
window.add(button)
window.show_all()

gtk.main()

To je myslím čitelnější než Ruby. Například je v Pythonu jasně vidět rozdíl mezi předáním odkazu na metodu (např. gtk.main_quit) a mezi voláním metody (např. gtk.main()). V Ruby to není rozlišeno, to velmi stěžuje čtení takového programu, není na první pohled jasné co program dělá.

[Marek Bernát]

To iba hovorí, že PyGTK je lepšie ako PyQT. Ak sa chcete baviť o QT vs GTK (čo je IMHO dosť zbytočná debata), tak ukážte kód v natívnom jazyku v oboch toolkitoch.

To že je nejaký wrapper lepší ako iný, nehovorí o toolkite nič.

A Ruby vs Python sem tiež nepatrí. Každému, čo jeho jest.

[pm]

No, přinejmenším to znamená, že je lepší v Pythonu používat GTK a myslím, že o Python zde jde v první řadě.

Navíc GTK je v C a Qt v C++, takže přímo srovnat nejdou.

[jean]

Jaky ma duvod je porovnavat v nativnim jazyku? Ano zjistite, ze C je vice nizkourovnove nez C++ (s jasne plynoucima vyhodama i nevyhodama), ale k tomu zrejme nikdo porovnavani nepotrebujeme ;). Jedina logicka vec je jejich porovnani ve stejnych jazycich - v jejich co nejvetsim poctu:

* C/GTK versus C/QT (na to jsem v QT opravdu zvedav ;)
* C++ v GTK versus C++ v QT (vetsina programatoru tvrdi, ze C++/GTK je lepsi, protoze maximalne vyuziva nove vlastnosti C++, a po shlednuti tohoto clanku tomu dost verim)
* Python/GTK versus Python/QT (na prvni pohled se zda, ze GTK je elegantnejsi a lepe navrzene).
* Ruby/GTK versus Ruby/QT (GTK je mnohem lepsi - QT wrapper neni nic jineho, nez programovani C++ v Ruby, stejne jako u PyQT)
* Java/GTK versus Java/QT
* Mono/GTK versus Mono/QT
* Perl/GTK versus Perl/QT
* PHP/GTK versus PHP/QT
...

P.S. Jeden z hlavnich cilu pri vyvoji GTK bylo, aby se na nej dobre vytvarely wrappery. Proto je taky udelany v C. Jeho programatori totiz netrpeli predstavou, ze jejich prog. jazyk je jediny spravny na svete, jak je tomu u hodne C++/PHP programatoru :) (bez urazky - konstatovani faktu - prosim noflame).

[Marek Bernát]

To že sú wrappery horšie alebo lepšie napísané, IMHO nezavísí veľmi od toolkitu. To závisí od ľudí, ktorí napísali wrapper.

A porovnanie v natívnom jazyku by ukázalo, aky je toolkit (nie wrapper).

Na druhej strane ak je GTK naozaj stavané na písanie "wrapperov", tak tá moja otázka stráca zmysel. Potom by aj pre mňa GTK rozhodne bolo zaujímavejšie. Dokonca až tak, že sa naňho asi pozriem a uvidím, čo uvidím

[jean]

"Ano, GTK je lepší toolkit než Qt"

To s vami souhlasim, akorat me po tom, co jsem vsude cetl Qtckare se vytahovat, jak uzasne jsou v Qt delany signaly, docela udivuje, ze jsou az takhle nepekne.

"Například je v Pythonu jasně vidět rozdíl mezi předáním odkazu na metodu (např. gtk.main_quit) a mezi voláním metody (např. gtk.main())"

To je v Ruby taky, protoze GTK.main_quit nikdy nebude nic jineho, nez volani metody. V Ruby totiz neni nic jineho nez volani metod. Odkazy se delaji jinak. Coz je v Ruby myslim lepsi, nez v Pythonu, protoze netreba psat prazdne zavorky ;) (viz napriklad GTK::Button.new a puts "hello" a str.strip.reverse.split, atd.). Uznavam ale, ze je to pouze drobna vychytavka pro pohodli programatoru, takze se o tom netreba dohadovat.

Na prvni pohled nevidite, co program dela, protoze neznate bloky, to je cele. Ale netreba zoufat, myslim ze novy Python se inspiroval a bude je mit taky. Samozrejme ze budou muset byt nejakym zpusobem ohnute, aby do Pythonu pasovaly, ale porad lepsi nez klackem do oka ;).

P.S. Odkazy na metody jsem prakticky v Ruby jeste nevidel pouzivat. Vsechno se resi pres bloky, coz je imho uplne jina liga.

[pm]

OK, v tom případě jsem ukázku Ruby nepochopil, příliš se odlišuje od konvenčních jazyků které znám. Každý si musí posoudit, jak moc se mu tahle vlastnost zdá nevýhodnou.

Zajímalo by mě, jak u vás zavěsit jeden a ten samý handler na víc signálů. Přeci nebudu ke každému takovému signálu psát handler do bloku znova. V Pythonu se jednoduše předá odkaz na funkci handleru. Jestliže se v Ruby odkazy nepoužívají, jak na to?

[Martin Povolny]

treba tak, ze udelam novy Proc a predam ten Proc.

neco jako:

handler = Proc.new { |arg| .... }

button1.signal_connect( "clicked" ) { |w| handler.call(w) } button2.signal_connect( "clicked" ) { |w| handler.call(w) } button3.signal_connect( "clicked" ) { |w| handler.call(w) }

ale mozna to pujde i elefantneji, uz jsem v tom dlouho nic nedelal...

[pm]

Tak uvidíme, protože tohle se mi zdá jako horší řešení, než v Pythonu.

[jean]

"Každý si musí posoudit, jak moc se mu tahle vlastnost zdá nevýhodnou."
Tenhle argument jsem slysel prilis casto od PHPkaru, kteri tim argumentovali proti Pythonu, nez abych to vice komentoval...

Ad. vice signalu: napriklad zdedenim Buttonu a predefinovanim signalu, nebo predanim toho sameho bloku nekolikrat:

muj_signal = proc { puts "Hello" }

button1.signal_connect("clicked",  &muj_signal) 
button2.signal_connect("clicked",  &muj_signal) 

Samozrejme to lze udelat i odkazem na metodu.

[pm]

No, a jsme prakticky u Pythoniho reseni .

[jean]

Bohuzel nejsme :). Jak jsem psal, bloky jsou vic nez metody. Jsou to tzv. closures. Jestli closures jeste neznate z Pythonu (myslel jsem ze nejnovejsi verze je uz umi), tak je stoprocentne budete znat z JavaScriptu, kde se taky hojne pouzivaji.

Protoze Ruby zrejme neznate, nebudeme asi zbytecne pokracovat v diskusi. Zkuste si precist tento text od Pythonisty, ktery oba jazyky srovnava: Ruby and Python. Je to ale ponekud starsiho data...

Ja to vidim podobne jako tvurce Ruby on Rails:

Yes, functionally, Ruby and Python are really close. In terms of elegance and consistency, though, Ruby feels (this is both subjective and non-quantifiable) way ahead to me. Especially when it comes to the level object-orientedness and the widespread use of blocks.

[pm]

Ale jsme, nazyvat to muzete jak chcete, ale vase reseni:

muj_signal = proc { 
    puts "Hello" 
}

button1.signal_connect("clicked",  &muj_signal) 
button2.signal_connect("clicked",  &muj_signal) 

se nijak nelisi od reseni v Pythonu:

def muj_signal(butt):
    print "Hello"

button1.connect("clicked", muj_signal)
button2.connect("clicked", muj_signal)

Jen by me zajimalo, jak dostanete do toho sveho bloku promenne, ktere ten signal predava. Ze byste musel pouzit jeste jine reseni?

[jean]

Funkce v Pythonu nejsou skutecne closures, i kdyz je to mozne obejit jednoduchym trikem: http://mail.python.org/pipermail/python-list/2004-July/229478.html . OK, uznavam ze jsem se spletl, a ze python skutecne closures jeste neumi - uz jsem v nem dlouho neprogramoval :(. Na druhou stranu tomu jiz mnoho nechybi....

Jestli vam jde o to nalezt takove zadani, aby se nedaly efektivne pouzit bloky nebo alespon closures, tak co treba implementace algoritmu 1+1 ;) ?

Tak tady je to teda s jednou promennou, se dvema to ale uz psat nebudu:

muj_signal = proc {|button| puts "Hello" }

button1.signal_connect("clicked",  &muj_signal) 
button2.signal_connect("clicked",  &muj_signal) 

Jestli chcete o Ruby vedet neco vic, tak si o nem prosim prectete tuhle knizku: http://www.ruby-doc.org/docs/ProgrammingRuby/ - uz me to tu nebavi :(.

Abych tuhle diskusi uzavrel, tak opakuji jeste jednou, co se tyce funkcionality, jsou na tom Python i Ruby obdobne. A budou si porad bliz, protoze vetsina jazyku zacala Ruby featury postupne implementovat (Python, novy Perl, jazyky nad .Netem, ...). Pak uz je rozdil pouze v tom, zda je jazyk pro dane featury primo navrzen, nebo jsou do jazyka postupne dosroubovany.

[pm]

Nejde mi o nalezení neproveditelného zadání, jen mě zajímá, jakou podivnou syntaxi si ruby zvolilo pro takové běžné a jednoduché záležitosti. Jak jsem uvedl, nazývejte to jak chcete, ale z praktického hlediska je to to samé řešení jako v Pythonu.

Nevím proč mi píšete, že vás o tu nebaví, sám jste s v dikuzi pod článkem o Pythonu rozhodnul dělat osvětu o Ruby či se jím spíše vytahovat. Tak toho využívám a snažím se něco dozvědět. A zároveň vám ukazuji, že Python v ničem nezaostává, jen mi přijde jeho způsob zápisu srozumitelnější, protože je bližší konvenčním jazykům.

Pokud byste náhodou i nadále chtěl vést osvětu, tak by mě zajímalo, jak proměnné toho bloku přiřadíte libovolnou defaultní hodnotu. Něco jako:

def mujSignal(button=None):
    pass

[jean]

"jakou podivnou syntaxi si ruby zvolilo...protože je python bližší konvenčním jazykům"

Umim dobre spoustu prog. jazyku, takze mi nenamluvite ze ma Python syntaxi podobnou konvecnim jazykum, nebo ze neni v mnoha ohledech velmi podivna. I ten priklad co jste tu ted uvedl nema s konvencnimi jazyky vubec nic spolecneho a kdyby jste ho napsal do diskuse o C/PHP/Perlu/Ruby/Jave/... tak by nad ni vsichni ohrnuli nos.

"Nevím proč mi píšete, že vás o tu nebaví, sám jste s v dikuzi pod článkem o Pythonu rozhodnul dělat osvětu o Ruby"

Nemam v umyslu tu ztracet cas vyvracenim demagogie :(. Uvedl jsem zde priklad, ktery je elegantnejsi, nez v Pythonu. Potom jste mne primel napsat priklad, ktery je podobny alternative v Pythonu, ale je silnejsi. Tady je o neco slozitejsi priklad, ktery je znovu o dost jednodussi a elegantnejsi nez jeho pripadna alternativa v Pythonu:

5.times {|i|
    button = Gtk::Button.new("Hello_#{i}")
    button.signal_connect("clicked") { puts i }
    vbox.add(button)
}

Takhle bychom mohli pokracovat nekolik let, ale postradam v tom smysl (podobnych srovnavacich stranek existuji desitky). Zkuseny Pythonista nema duvod prechazet na novy jazyk (i kdyz mu neuskodi dalsi jazyk se naucit) a zacatecnikum jsem zde ukazal, ze existuje stejna nebo dokonce lepsi alternativa k PyQt a PyGtk, ktera stoji za to aby se na ni podival. Jak jste jiz psal, at se kazdy rozhodne sam...

To uz je opravdu konec - at uz vymyslite libovolnou provokaci ;).

[Martin]

Tady je o neco slozitejsi priklad, ktery je znovu o dost jednodussi a elegantnejsi nez jeho pripadna alternativa v Pythonu:

5.times {|i|
    button = Gtk::Button.new("Hello_#{i}")
    button.signal_connect("clicked") { puts i }
    vbox.add(button)
}

To si nemyslím, vy jen asi Python příliš dobře neznáte.

for i in xrange(5):
    button = gtk.Button("Hello %d"%i)
    button.connect("clicked", puts, i)
    vbox.add(button)

[jean]

Mel jsem pouzit o neco malo slozitejsi kod - pak by vam uz zadny triky s predanim jedne promenne nepomohly - co treba deset promennych a pak s nimi provest nejakou netrivialni operaci ;). Obecne, vse co se v Ruby resi jednim konzistentnim zpusobem pomoci bloku, to se v Pythonu musi resit ruznymi triky - viz take stranky, ktere jsem jiz posilal.

Zkuste to ted napsat tak, aby to melo stejnou silu jako Ruby predloha. Byla to tedy stejne silna alternativa, o kterou me slo, a kterou lze resit temer vsechny problemy daneho typu (mimo zmenu promenne o uroven vyse, kterou Python neumi) a nemusi se na kazdy podobny problem vymyslet jiny trik (lambdy, generatory, ...). Myslim tim dve zanorene funkce...

P.S. Defaultni parametry do bloku samozrejme predavat lze. Uz jsem tu ukazal i priklad, kdy lze parametr uplne zahodit. Kdyby se vas kolega na ruby podival alespon z rychliku, nemusel by tu psat porad takove bludy ;). Navic si u kazdeho signalu muzu konecne volani prizpusobit, jak uznam za vhodne. Muzu tak pouzit naprosto nekompatibilni handler. Samozrejme zase konzistentnim a elegantnim zpusobem - pomoci bloku.

[Petr Mach]

Možná by ohrnuli nos (nemám ale takovou zkušenost), ale tomu kódu by rozuměli, a to je podstatné, srozumitelnost. Nesnažte se popřít nepopiratelné, syntaxe Pythonu je podobnější dominující Clike syntaxi a tím je bližší (srozumitelnější) programátorům než Ruby.

Ad. příklad. Jak na to v Pythonu ukázal někdo předemnou, nic zvláštního. Ale nepřehlížím, že v Ruby nedovedete předávat defaultní parametry.

Mně nejde o nějaké honění si trika natož demagogie. To na co se vás ptám jsou jednoduché a praktické věci, o kterých ze zkušenosti vím, že jsou užitečné. Používat jeden handler pro víc signalů je naprosto běžné. V GTK je i běžné, že co signál, to různý počet parametrů. Jak použít jeden handler pro víc signálů které předávají různý počet parametrů? V Pythonu, jak jsem ukázal, jednoduše použiji defaultní hodnoty parametrů u handleru. Defaultní hodnoty jsou vemi užitečné a používají se při řadě příležitostí, jestli je bloky v Ruby neumí, pak konstatuji, že funkce v pythonu jsou promyšlenější.

Můžete Ruby považovat za elegantnější, to vám neberu, je to čistě subjektivní záležitost, mně přijde elegantnější Python. Zdá se však, že Python je objektivně promyšlenější a praktičtější, protože v něm jedním konzistentním způsobem (odkazy na funkce) řeším všechny možné požadavky na callbacky. A to je to, co se počítá.

BTW já vás nepříměl napsat priklad, ktery je podobny alternative v Pythonu. Já chtěl vidět jak se v Ruby řeší callbacky prakticky na příkladu z praxe, a ne na školní maximálně zjednodušené ukázce. Řešení jste mohl zvolit jaké chtěl. Že se praktické řešení v Ruby neliší od toho v Pythonu mě nijak nepřekvapuje .

[Martin]

Můžeš mi prosím vysvětli, co myslíš tím slovem closure? Nějak to nechápu a ani googlování mi moc nepomohlo. Děkuji.

[jean]

Jeden odkaz jsem uz posilal, je to tam vysvetleno na prikladech v Pythonu:
http://mail.python.org/pipermail/python-list/2004-July/229478.html

Dalsi odkazy, kde se obchazi neexistence closures a bloku v Pythonu pomoci lambd a podobne:
http://ivan.truemesh.com/archives/000411.html
http://ivan.truemesh.com/archives/000392.html

Stranky Pythonu na wikipedii, kde tvrdi, ze umi closures (ale ve skutecnosti je k tomu potreba pouzit triku v prvnim odkazu):
http://en.wikipedia.org/wiki/Python_programming_language
(je tam odkaz i na wikepedia stranku o Closures)

[Martin]

Já jsem asi hloupý, ale vůbec ti nerozumím. Ptám se, co je closures, ty mi dáváš odkaz kde to je vysvětleno v Pythonu a hned na to další odkaz, který dokazuje neexistenci closures v Pythonu? Jsem teď tak zmatený, že si ani nejsem jist, jestli v Pythonu closures jsou nebo ne.

Na ty odkazy jsm koukal a nepochopil z toho, co ty closures mají být. Mohl bys mi prosím ty sám, srozumitelně a česky, bez odkazů, vysvětlit co to ten closure je a k čemu je to dobré? Já si ani nejsem jist, jestli to má být nějaká konstrukce jazyka jako je třeba funkce nebo třída, nebo spíše nějaké specifické chování čehosi jako je třeba dědičnost nebo přetížení.

Jestli je to možné, prosím o vysvětlení bez vazby na nějaký konkrétní jazyk. Děkuji.

[Petr Mach]

Nehledej za tim zadnou vedu. Closures jsou uzavrene (soukrome) prostory jmen, do kterych se obvykle zapouzdruji funkce. Je to neco mezi lokalnim a globalnim prostorem jmen. Rozdil oproti lokalnimu prostoru jmen je ten, ze zustava zachovan i mezi volanim funkci. Rozdil oproti globalnimu prostoru jmen je ten, ze kazda funkce ma svuj vlastni.

Pouziti je ruzne, muze to slouzit jako nahrada direktivy static nebo nastaveni defaultnich parametru u nejakeho generatoru funkci.

Python podporuje vnorene prostory jmen, takze closures umi. Jen se musi pamatovat na jeho automaticke prekryvani nazvu promennych, ktere muze trochu zkomplikovat pristup z lokalniho do closure prostoru jmen. Vyresit by to mohla alternativa direktivy global nazvana treba closure, ktera by promennou hledala v nejblizsim nadrazenem prostoru jmen a ne tom nejvyssim jako to dela global.

[Lukáš Zapletal]

Uzávěry se dají použít třeba k jednoduchému zapouzdření dat...

[Daniel Kvasnička ml.]

Ano, GTK je lepší toolkit než Qt

jj, to urcite. a nejlip je na tom GTK s pametovymi naroky a naroky na procesor, ktere jsou zcela jiste mensi, nez u Qt. A taky ma hlavne na vsech OS nativni look, to kazdopadne

[JM]

* ano, GTK ma mensi pametove naroky - je to videt uz na socku
* ano, GTK ma na vsech OS nativni look - na Windows dlouho (spec. tema) a na OSX nove.

[Daniel Kvasnička ml.]

ano, GTK ma mensi pametove naroky - je to videt uz na socku

a co GNOME...to si za tu lennost muze samo? Kdykoliv jsem porovnaval veci v GTK a Qt, Qt bylo sviznejsi a chovalo se k pameti slusneji.

ano, GTK ma na vsech OS nativni look - na Windows dlouho (spec. tema) a na OSX nove.

vy asi vaze nemate poneti, co to je nativni look. Pokus o imitaci WinAPI se jakz takz zdaril, i kdyz file chooser a dalsi veci porad nejsou prizpusobeny. Ale rikat nedavnemu rozchozeni GTK+ na OS X bez X serveru nativni look...za to by vas jakykoliv Macar ukamenoval. Pokus je to hezky a mnoho veci zjednodusi, ale uz jen to, ze menu aplikace neni tam, kde ma byt, je z pohledu uzivatele OS X neodpustitelny prohresek. A to radsi nemluvim treba o klavesovych zkratkach ci desgnu toolbaru, ktere ztezi budou nekompromisne vyhovovat Apple HIG...

[JM]

Stejny python program v Qt a GTK:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21016 jiri      15   0 29140  14m  11m S  0.0  2.8   0:00.84 python-qt
21056 jiri      15   0 16640 9.9m 6464 S  0.0  2.0   0:00.45 python-gtk

Kdyz v Gnome na neco cekam, tak je to disk. Problem s Linuxovyma GUI aplikacema je podle mne v tom, ze otviraji prilis velke mnozstvi souboru. Tohle to jen potvrzuje:

Dave Jones, recently did some profiling of what’s called through the kernel during startup. He
traced stat()s, open()s, and commands exec()ed. There were some pretty
amazing results. Some of the highlights include:
   * Executing /sbin/hotplug 317 times
   * Over 470 exec() calls during startup
   * cups, during startup stats 1212 times and opens 172 files
   * cups fires up printconf-backend which does another 1304 stats and
     155 opens
   * hal does 1980 open calls and 7106 stat calls. Dave says “Wow.”
   * Xorg during startup does 2420 stat calls and 370 open calls
   * gdm calls stat 1871 times and 314 open calls. And it opens 126
     fonts.
There’s a lot more than that, but those are the highlights.

Nevim, jestli uz Qt dela double buffering - GTK ho dela. A nejpomalejsi je samozrejme Pango, ktere na druhou stranu nema v kvalite u Qt alternativu - nebo uz ano?

Opravdu vim, co je to nativni look, ale vy jste si to zrejme spletl s "native look and feel". Jo, to je presne to, co mi Qt na mem desktopu kazi ;). Proto nepouzivam zadne Qt aplikace.

Ja se sice v OS-X nevyznam, ale tohle mi pripada, jako ze ma menu nahore: http://gtk-cocoa.sourceforge.net/Gtk+-Cocoa.jpg . Mam pocit, ze se ty veci pro OS-X porad vyviji, takze bych je za pouhy pokus zatim neoznacoval.

Navic tady programujeme v Pythonu, takze nam jde hlavne o rychlost a jednoduchost vyvoje a myslim si, ze zrovna OS-X u nas moc resit nemusime. Plus napriklad me docela na Linuxu zalezi, takze radsi budu podporovat toolkit, kterej z Linuxu nedela kripla z hlediska komercniho vyvoje.

[Kyosuke]

"Například je v Pythonu jasně vidět rozdíl mezi předáním odkazu na metodu (např. gtk.main_quit) a mezi voláním metody (např. gtk.main()). V Ruby to není rozlišeno, to velmi stěžuje čtení takového programu, není na první pohled jasné co program dělá."

Tak to se mýlíte, protože zápis něco.něco_jiného je v Ruby vždyvolání metody, stejně jako ve Smalltalku.