Wireshark přechází na Qt (diskuse)

[Sešívaný]

"...potýká se s nedostatky GTK+" Vývojáři Wiresharku zmiňují přesně jeden nedostatek: špatný stav portu GTK+ na OS X, pro který chtějí kvůli poptávce Wireshark dělat. To je celé.

[Rovano]

Záleží na úhlu pohledu. U QT je to zase killer feature.

[Sešívaný]

Šak já neříkám, že ne. Jen mi přišlo, že zprávička vyznívá, jakoby vývojáři zápasili s nedostatky v GTK+ a proto se na něj vykašlali a šli ke Qt. Přitom jen prostě chtějí udělat port pro OS X a zjistili, že na OS X je na tom Qt mnohem líp.

[radek]

Nemusime se bat. Urcite se nekdo odstepi a bude dal vyvyjet pro gtk :))

[pavlix]

To mi přijde zbytečné. Je to specializovaný tool, jehož uživatelé snad nějakou tu závislost navíc překousnou.

[Kaacz]

Jenže nejde jen o port na MacosX. Obecně je Qt mnohem více multiplatformní než Gtk.

Na tabletu/mobilu Gtk nikdo nepoužívá. A je trend nepsat aplikaci znovu pro každou platformu. Viz třeba MeeGo, kde jednou napsaná aplikace vypadá různě podle QML knihoven pro mobil/tablet/tv/auto ..

Ano, nadstavby typu QML, Qt Quick a podobně jsou pro vývojáře ten správný směr a Gtk jako desktop-only fosilie zajde samo .. bude čím dál méně lidí, kteří to budou používat a vyvíjet. Poslední dobou se dotáhly různé java/python/ruby bind s QML/Qt .. tam směřují vývojáři.

Ubuntu phone je na QML/Qt, Unity se mění na Unity Next také s QML/Qt ..

Dále se maká na Qt5 (+QML) a jeho funkčnost nad Wayland - to jsem zvědav, protože to budu mít na mobilu. :) A možná vznikne i Wireshark pro mobil. To by se mi taky hodilo. :)

Nebude trvat dlouho a na Gtk zůstanou jen základní Gnome aplikace .. a tiše spolu zmizí v propadlišti dějin ..

Prostě - aplikace která zůstane na Gtk je odsouzena živořit jako desktop-only trilobit..

PS:

Kdysi dávno (před začátkem vývoje Gtk3) v Canonicalu uvažovali postavit nový Gnome desktop nad QT. Není to problém, Qt se dá "skinovat" do úplně jiného vzhledu. Byla by to paráda, ubyla by půlka knihoven.. Jenže pak se rozhodli pro vývoj Gtk3 .. :(

[Kaacz]

Zapomněl jsem zmínit QML/Qt na BB10 a SailfishOS.. prostě se to šíří jak virus .. :)

[vain]

Třeba jako Windows?

[David Šmíd]

Qt taky už podporuje Android, iOS a existuje komunitní port pro Tizen.

 

---

[progdan]

Na iOS zatim bohuzel pokud vim, chybi podpora pro QML.

[little.owl]

existuje komunitní port pro Tizen.

To je pomerne nedavna vec, tlaci se to tam navzdory Intelu a Samsungu par lidi a dokud to bude mit v rade veci treba polovicni framerate oproti EFL, ruzove to nevidim.

[chrono]

Pre GTK+ aplikácie sa dajú robiť oveľa komplikovanejšie skiny, takže zrovna táto oblasť nie je doménou Qt.

[xin]

Jo, ale o skiny tady nejde.

[R]

A kolko ich existuje a ktore z nich funguju vo viacerych verziach GTK?

[kralyk z abclinuxu]

Skiny pro aplikaci bych viděl jako nevýhodu - aplikace má zapadata do prostředí.

[chrono]

Skiny pro aplikaci bych viděl jako nevýhodu - aplikace má zapadata do prostředí.

To znie ako keby takú základnú vec skiny pre Gtk+ nevedeli. Každopádne mne vyhovuje, keď môže nastaviť to, čo potrebujem (v mojom prípade napr. farbu XFce panelu a tlačidiel na ňom na tmavší odtieň, ako majú ostatné okná).

[Conscript89]

To je trosku problem kdyz by potom napr. virt-manager vypadal jako mimozemstan v KDE (jen protoze pouziva GTK3) nebo naopak.

[n900kar]

na nokii n900 mam wireshark :)

[Rovano]

To mi tehdá přišlo jako krok špatným směrem, keď zakopali počínající Unity na QT... krásně to jelo na starých herkách se soft vykreslováním. Za to GTK s Compizem bylo děsně pomalé.

[Sešívaný]

Kdysi dávno (před začátkem vývoje Gtk3) v Canonicalu uvažovali postavit nový Gnome desktop nad QT. Není to problém, Qt se dá "skinovat" do úplně jiného vzhledu. Byla by to paráda, ubyla by půlka knihoven.. Jenže pak se rozhodli pro vývoj Gtk3 .. :(

Toto zní jakoby měl Canonical nějaký vliv na vývoj GTK+. Jenže vzhledem k tomu, že nemá v upstreamu GNOME a GTK+ žádné vývojáře, je jeho vliv prakticky nulový. A samozřejně, že se Canonical rozhodl postavit svoje prostředí na Qt/QML. Ubuntu je jako primárně GTK+ distro už jen dočasně.

[petr_p]

Gnome je ovládáno Red Hatem, psali to přece na LWN.

[Bedňa]

A Sešívaný tiež, tak mu to nemusíš písať :)

[Sešívaný]

petr_p taky :) Je to jedna velká konspirace.

[Bedňa]

Do prdele, som sa nechal nachytať :)

[Kaacz]

Pravda, já si to po těch letech moc nepamatuju. Jestli to byl šéfík z Canonicalu nebo Gnome. Já ty jejich věci nepoužívám.

[little.owl]

Na tabletu/mobilu Gtk nikdo nepoužívá.

To je pravda. A Qt na tom neni o nic lepe. Blackberry jde do haje, a Sailfish a Ubuntu Phone se jeste nedostaly do pozice, kdy by vubec mohli rici, ze z toho haje vylezly. O zbytku, kde QML/Qt hraje treti ligu vedle nativniho toolkitu, nema smyslu vubec mluvit.

[Rezza]

Jak to nakonec vypada s podporou Gtk na ne-linuxovych platformach? Jak Matthias mluvil o omezeni/vyhozeni podpory Windows na Desktop Summitu atd. Maji tam jeste nejake vyvojare?

[Sešívaný]

Podle mně se tomu nikdo příliš nevěnuje. Port na Widle asi bude v lepším stavu, ale taky žádný zázrak.

[Tomáš Bžatek]

A copak se za par cyklu asi stane s GDK X backendem, az bude Wayland default...?

[little.owl]

Muj dojem je, ze GTK jako multiplatformni toolkit konci.

[David Heidelberg]

...konečně. Osobně mě to potěšilo.

[Limoto]

Taky tak. Vždycky když to používám tak z toho mám takovej divnej pocit. Když nad tím přemýšlím, tak celkově v poslední době těch Qt aplikací používám víc a víc Vůbec su poslední dobou s Linuxovým desktopem s KDE spokojenej. Momentálně mám uptime 29 dní, bez restartu KDE, padání nějaké aplikace, podivnejch grafickejch artefaktů a podobnej věcí. Prostě všechno krásně funguje

[pepe_]

Tak tak , éra GTK zkončila u gtk2  a s nástupem gtk3 už všichni stejně přecházejí na QT.  Nejde ani tak o KDE4 , když QT bude modulární tak stačí pár knihovniček a například na LXDE pojede hezkej shark a zabere to jen pár mega bez bordelu.   http://www.youtube.com/watch?v=FIs5YqzS4Bc

[pepe_]

skončila

[Roslav]

Alebo si rovno nainstalovat LXDE-qt (spojenie LXDE a Razor-qt desktopu) a to uz nebude treba ani knihovna navyse :)

[Bedňa]

Momentálně mám uptime 29 dní, bez restartu KDE, padání nějaké aplikace, podivnejch grafickejch artefaktů a podobnej věcí. Prostě všechno krásně funguje

Klamať je hriech

[mankind_boost]

"Momentálně mám uptime 29 dní, bez restartu KDE, padání nějaké aplikace, podivnejch grafickejch artefaktů a podobnej věcí."

A o kolik procent za tu dobu vzrostlo využití paměti? Z 500 MB na 4GB?

[krab1k]

Tak ještě Inkscape a GIMP () a bude to všechno.

[xkucf03]

GTK+ znamená GIMP Toolkit

[Limoto]

Tak se to přejmenuje na GNOME toolkit

[chrono]

Stačí si prečítať na ich mailingliste Stock Items Deprecation a hneď bude jasné, že už dlho to je Gnome Tool Kit.

[krab1k]

Vím. Proto tam byl u GIMPu ten smajlík.

[Anon]

Qt verze GIMPu, Inkscape a Darktable a jsem v sedmim nebi...

[xkomczax]

Zkus jim to navrhnout, tebe s tímto nápadem třeba nepoženou jak jiné

[Kaacz]

A ten link vede na jiný zajímavý link o G a Q :)

[Anon]

Apropo, Inkscape už má v podstatě hotovej GTK3 port...

[Josef Kufner]

Nejvyšší čas začít s Qt portem.

[Jardík]

C++ je naho*no, přidáte podělanou virtuální metodu a rozbijete abi.

[little.owl]

+1

[Rezza]

A přesně na to má Qt přísná pravidla, přejatá z KDE a metodu, jak ABI řešit. A bez pravidel jako u kupu projektů je pak jedno, v jakém jazyce to je, když jsou vývojáři prasátka.

[Ivan]

Bohuzel to ani samo Qt moc neresi. Jasne, ze na to maji pravidla, ale je velice tezke je dodrzet. Na Linuxu to moc nepoznate, protoze se vsechno kompiluje se stejnou verzi QT. Ale na Woknach? To je nekdy peklo, kdyz mate nainstalovany dve Qt aplikace a kazda si sebou pribali svoji verzi QT knihoven.

Nektery fixy ABI zmenit musi. Navic taky zavisi s jakyma volbama, a hlavne jakym kompilatorem je QT zkompilovany.

PS: ja na QT az tak moc nevadavam. GTK jsem opustil ve verzi 1.2.3(kvuli nedostatku dokumentace) a vracet se k nemu nechci. Delat GUI v Ccku je nesmysl. Nedavno jsem koukal v cem je napsany "MySQL workbench" a to taky nevypada spatne. Ma to vlastni minimalisticky GUI "framework", ktery na Windows pouziva .NET GUI komponenty na Linuxu GTK a na OSX Cocoa. Na kazdy platforme to vypada nativne. Nema to zadny divoky zavislosti a pritom je to v C++.

[Rezza]

Prave na Linuxu je to vic poznat, kde je jedna verze Qt a nad ni prelozenych kopa aplikaci a pokud se nemeni ABI, tak se nerebuildi (aspon teda ne ve Fedore). U Qt si tusim pamatuji jednou bug, ktery ABI rozbil (stane se a to se stane i v cecku obcas, kdyz nekdo nepremysli.

[kralyk z abclinuxu]

Qt ta pravidla v rámci major verze dodržuje velmi striktně - nestává se, že by rozbili kompatibilitu ABI, a pokud by se to stalo, byl by to bug s vysokou prioritou, který by byl následně opraven. A na Linuxu se rozhodně nekompiluje všechno se stejnou verzí Qt.

To, že na Windows si aplikace přibalí každá svou verzi Qt není problém Qt, ale problém Windows, resp. absence správy balíčků.

[little.owl]

To, že na Windows si aplikace přibalí každá svou verzi Qt není problém Qt, ale problém Windows, resp. absence správy balíčků.

Ne, to je problem vyvojaru SW, kteri nepouzivaji nativni toolkity.

[Rezza]

No kdyz vidim ty vsechny bundlovane MS -redist veci, dot nety, tak asi jediny skutecne nativni toolkit na Windows je Win 32 API :).

[little.owl]

jediny skutecne nativni toolkit na Windows je Win 32 API

Presne tak, a chodi i to na Linuxu .

[Ivan]

To prave neni pravda. Windows maji spravu baliku (aka manifest sxs hell). Problem je, ze to vsichni - vcetne QT - ignoruji. Stacilo by, kdyby Digia vydala pro QT runtime knihovny redist package vcetne merge(.msm) modulu a bylo by to vyreseny.

Misto toho vsichni resi jaka verze Mingw je lepsi a jak zkompilovat program pro Windows bez toho aby vubec museli ty wokna nabootovat. Pritom by uplne v pohode stacilo nechc*t proti vetru a pouzivat to co funguje a to co doporucuje vendor OS. Na Linuxu se to dela taky tak.

[pavlix]

Na Linuxu se to dela taky tak.

Svatá pravda. Na Linuxu se taky „cizí živly“ snaží prasit, jak se dá, a používat postupy mimojiné naučené z Windows.

[kralyk z abclinuxu]

Já se nedivím, že oni to SXS nepoužívají, ono by to v zásadě nic neřešilo. Jestliže by vycházely redist verze Qt, tak by tyto verze Qt akorát končily ve winsxs, odkud už by je nikdo nikdy nedostal, protože SXS řeší upgrady tím stylem, že starou verzi tam nechá a novou prostě nainstaluje vedle té staré. Takže v zásadě je imho skoro spíš lepší, když si ta aplikace svoji verzi Qt přitáhne s sebou, protože při odinstalaci ji zase smaže.

Imho nejlepší možnost je aktuálně statické linkování, pokud se to v konkrétním případě dá použít.

[little.owl]

C je na tom zde lepe a kupa pravidel u C++ to nezchrani, zejmena pokud pouzivate na ruznych platformach ruzne kompilatory.

[Šangala]

Měli raději přejít na Motif, ať není za chvíli všechno jen Qt (mimo GIMP-u).

[Jindřich Makovička]

Nebo rovnou na Athenu, minimalistický design je teď v módě.

[pc0]

Qt ~ Digia <- Microsoft <- Nokia <- Trolltech

Moc bych nad vyuzivanim Qt nejasal. Uz jednou kousnul odprodej Nokii, kterou nasledne zariznul MS. Ted ji drzi a vyviji ciste komercni Digia, porad se prodava komercni licence a je otazka jak moc dobre, protoze to muze mit vliv na odstaveni prostredku pro dalsi vyvoj.

Imho na forknuti a vylepsovani tady neni potencial. Qt3 a KDE3 budiz prikladem.

Btw. souhlas s kritikou C++ a to jak ho v tom frameworku ohli jako zatazeni mechanismu signalu a slotu.

[Rezza]

Jako ohnuti C++ je mega velke :). Diky tomu se to da pouzivat, ale s novym C++ uz to trosku zase davaji dohromady. Duvod byl - kdysi davno byly prekladace bud spatne, nekompatibilni atd., ze tam radsi hodili moc.

Qt je ted pod open governance, ale proste placene developery potrebuje. Takze ano, pokud to pusti Digia, bude to horsi. Pokud umre BlackBerry, bude to horsi. Komunita asi neco tak velkeho jako Qt na tolika platformach nezvladne, duvod proc prave kluci z Gtk uvazovali o umrtveni Gtk na jinych platformach nez Linuxu. I kdyz ted v 5.2 bude mega moc kodu portovaneho z KDE, co tak sleduji. Cilem je zabit potrebu velke casti custom veci v KDE, ktere existovaly kvuli nedokonalosti Qt pod tim a nemeznosti ten kod zaclenit.

[little.owl]

Qt je ted pod open governance,

Komicke je jak Digia tohle interpretuje podle toho s kym mluvi.

Takze ano, pokud to pusti Digia, bude to horsi.

Nemyslim, ze to pusti.

Pokud umre BlackBerry, bude to horsi.

Umre, s temihle prodeji neudrzi platformu, a nebo dopadne jako vyrobce marginalnich reseni.

[Rezza]

Komicke je jak Digia tohle interpretuje podle toho s kym mluvi.

Tak to znam, to funguje uplne stejne i v Red Hatu . Proste cisla commitu, rikaji ano, ale o budoucnosti se rozhoduje interne.

BB10 by byla skoda, v soucasne dobe nema konkurenci, ale firma to moc nechce prodavat.

[Luboš Doležel (Doli)]

Ted ji drzi a vyviji ciste komercni Digia, porad se prodava komercni licence a je otazka jak moc dobre, protoze to muze mit vliv na odstaveni prostredku pro dalsi vyvoj.

Kam lidi chodí na názor, že se Qt neprodává. Viděli jste vůbec někdy finanční výsledky býv. Trolltechu?

[little.owl]

Podle Q2 Interim Report Digie, prodeje Qt cini cca 7e6 eur z cca 50e6 eur a Qt jiz davno neni jejich klicovy business.

[Rezza]

Tak ono hlavne Qt je hodne drahe :(.

[little.owl]

To jednak a hlavne pro C++ multiplatformni toolkit neni zadny velky trh.

Na mobilnich systemech se to neprosadilo, u jednoucelovych masove vyrabenych zarizeni to zabiji licencni poplatky a dostupne free alternativy, a zbytek, nejake maloseriove multiplatformni aplikace a OSS tomu velky rozvoj neumozni.

Znam nekolik produktu vyrabenych ve statisicovych seriich, ktere budou vyrazeny od cca 2015, ktere byly postavene na MeeGo IVI a nove budou postavene na Tizen IVI bez Qt, nejspise na EFL.

[dad]

mam v Qt vastni tridy, napr. myLabel, myButton .. atd a u kazde z nich je metoda nastav_pos_X(..). Kdyz mam v programu pointry na tyto objekty, jak vyvolam tu metodu? Jeste porad se v Qt musi uhadnout o jaky objekt se jedna a pak si pomoct s dynamic_cast ?

[Ivan]

Jeste existuje "qobject_cast", ktery by mel byt rychlejsi. Popr. muzes pouzit QMetaObject::className anebo QMetaObject::enumerator. QT se snazi pridat do C++ reflexi, coz muze byt velice pohodlne na pouzivani, jen se to nesmi prehanet.

[dad]

no ja nevim, nakolik jsem se dobre vyjadril. Ta metoda QMetaObject:className vraci jmeno te tridy, ktera se za tim konkretnim objektem skryva a pak je mozno v nejakem switch konstruktu (nebo else if) vyvolat za pomoci 'nejakeho_cast' tu konkretni metodu nastav_pos_X(). Ale zjistit to jmeno te tridy lze i normalnich objektu v Qt, k tomu bych to QMeta asi nepotreboval?

Me jde o to, zde je mozno se vyhnout tomu rozhodovani v tom switchi nebo else-if. V jinych toolkitech to jde, tam zavolam metodu, ktera je implementovana uz v tom QObjektu ( a proto ji znaji vsechny odvozene widgety) ta metoda (nejak, hash, binarni vyhledavani nebo buh vi co) najde tu spravnou konkretni metodu.

[Ivan]

Takhle obecne se to neda zodpovedet. Musis uvest konkretni pripad. Pokud jsou obe instance widgety, tak urcite maji spolecneho predka QWidget (nejen QObject).

Je mozne ze v QT existuji dva ruzne widgety, ktere implementuji metodu stejneho jmena, ktera neni zdedena od spolecneho predka. To nemuzu vyloucit. Pak opravdu musis pouzit nejaky typ cast-u. (dynamic_cast, anebo qobject_cast). Zrovna tohle je obrovska vyhoda QT, ma dokumentaci, a v te se da najit i to od ktereho predka byla, ktera metoda zdedena.

Myslim ale, ze mas spis problemy s C++ jako takovym nez s QT.

[little.owl]

Postupem casu dochazim k zaveru, ze vytvaret masivni dedicne objektove hierarchie v projektech je cesta do (_!_).

[pavlix]

Tak tak, lepší je vytvářet užitečné dědičné objektové hierarchie, které umožní se v naprosté většině případů vyhnout introspekci dle jména.

[Ivan]

Pokud tu hierarchii vytvori jeden clovek (jeden tym) a zdokumnetuje to, tak je to jeste v pohode. Kdyz se to ale dostane do situace kde "pouzivam knihovnu" == "vytverim potomky" tak to nemuze fungovat. Navrhnout API tak aby se dalo snadno dedit je prakticky nemozny. Kazdou chvilu natrazite, na to ze potrebujete pristup k privatnim metodam, anebo ze nevite v jakem poradi se budou vase virtualni metody volat.

Na tomhle byl(je) postaven C++ XPCOM v Mozille, tam vam max. rekli ktere metody musite implementovat ale uz se nedalo dohledat jestli dana trida musi byt thread-safe a ve kterem vlakne se bude vykonavat ktera metoda. Takze to skoncilo tim, ze abych mohl implemntovat jedno rozhrani, tak jsem musel vsechny precist zdrojaky vsech dostupnych implementaci.

[kralyk z abclinuxu]

Je mozne ze v QT existuji dva ruzne widgety, ktere implementuji metodu stejneho jmena, ktera neni zdedena od spolecneho predka.

Pokud vím, tak tohle by se s QWidgety většinou stávat nemělo, od toho tam jsou takové ty různé QAbstract... věci.

[dad]

Myslim ale, ze mas spis problemy s C++ jako takovym nez s QT.

to je vic nez pravdepodobne, c++ me nijak nevoni, svet je ale zly a musim s tim pracovat. rad se ale dovim vice.

Jestli jsem ty navrhy ohledne dedicnosti a toho ucebnicoveho pristupu spravne pochopil, tak udelam nasledujici.

Nejdrve odvodim myWidget z QWidgetu. V tom napisu ty me virtualni metody. Pote odvodim z myWidgetu ty ostatni widgety, napr scrollarea->frame->label. Zopakuji vicemene to same, co udelali vyvojari Qt s temi vlastnimi widgety. A v tech konkretnich odvozenych widgetech pak implementuji ty konkretni metody.

Je to takhle mysleno?

Jen pro upresneni. Jsou jine toolkity, kde odvodim myWidget z nejakeho konkretniho , ktery je jiz soucasti toolkitu a v nem realizuji me metody. Tyto metody pak mohu pouzit v jakekoliv casti programu, aniz bych musel delat _cast_. Ten toolkit mi dava nejakou obecnou metodu k dispozici, pomoci ktere jine metody vyvolam. To je podle me inzenyrsky pristup.

[kralyk z abclinuxu]

V zásadě ano, ale možná by bylo dobré, kdybys napsal o co konkrétně ti jde, může existovat lepší / méně pracné řešení...

[vencas]

Říká se, že spousta lidí se snaží naprogramovat rychlejší obdobu virtuálních funkcí, ale nikomu se to nepovede (mám s tím zkušenost, prostě ty, kdo píšou kompilátory, zrovna tohle umějí udělat ďábelsky rychlé - je to často jen čtení jednoho či dvou pointerů navíc). className bude určitě pomalejší řádově, to se musí alokovat paměť pro řetězec a pak ho porovnat s jiným.

[pavlix]

Je otázka, jestli se skutečně snaží naprogramovat rychlejší obdobu virtuálních funkcí.

[little.owl]

Hlavne mi prijde, ze rychlost virtualnich funkci jiz neni takovy problem, pokud se neudela nejaka prasarna a nevola treba v loopu pro kazdy pixel.

[progdan]

Typicke reseni z OOP ucebnice je, aby myLabel a myButton meli stejneho predka myWidget, ktery nastav_pos_x() implementuje, tudiz pak neni potreba hadat, jestli je to pointer na jedno nebo na druhe, ale staci udelat dynamic_cast (nebo qobject_cast, jak bylo zmineno, ale ten je o neco pomalejsi nez standardni casty) na myWidget*

[mankind_boost]

"ale staci udelat dynamic_cast"

V tvém příkladě by stačil static_cast ne? Tohle může řešit kompilátor už při kompilaci, není potřeba v runtime.

[kralyk z abclinuxu]

Nevím přesně, čeho se tazatel snaží dosáhnout, ale pravděpodobně bude nejlepší těm třídám dát společnýho předka a v něm tu metodu definovat jako virtuální abstraktní. O zbytek se postará vtable.

[uhle]

To přece nemá co do činění s Qt, vždyť je to C++ 101...

[frdrx]

Učebnicový příklad tendenčně napsané zprávy.

[msk]

Mna na QT akurat mrzi, ze odkopli QtJambi. Takze sa s tymto frameworkom bohuzial stretavam len ako uzivatel.