Ardour pouze s YTK (fork GTK2) (diskuse)

[xkucf03]

To zní zajímavě. Třeba to jednou dospěje do stavu, že to půjde použít i v jiných aplikacích.

[AsciiWolf]

Především bude zajímavé sledovat, jak na tom YTK bude s podporou moderních technologií a standardů. Namátkou třeba Wayland či HiDPI.

[Peter Golis]

Pokiaľ bude pracovať s DPI ako s fyzickou hustotou obrazových bodov, tak v tom nevidím ani najmenší problém.

[bindiff]

Nečetla jsem to až do takové hloubky, ale dalo by se předpokládat, že tomu bude „pod kapotou“ běžet současné GDK, Cairo, Pango a další GTK-related knihovny. Pokud ano, tak s Waylandem není problém, ten řeší GDK. HiDPI je větší oříšek, ale dokud se kreslí přes Cairo (tzn. ± vektorově), tak taky nebude bolet až tak moc…

[OldFrog {Ondra Nemecek}]

Ani se nedivím, že nemají kapacitu donekonečna migrovat na nové a nové verze GUI toolkitu.

Osobně nechápu, proč není déle držena zpětná kompatibilita a není nějaký mechanismus volitelných improvements (slinkuju starý program s novým GTK a nemusím využívat ty featury, které by vyžadovaly dodatečné programování a práci navíc). To se tolik mění vnitřní architektura? Jak to má řešené QT? A co na to Jan Tleskač?

[xkucf03]

+1

QT ma tohle imho resene mnohem lepe. Navic je C++ preci jen na GUI lepsi nez ciste C s makry preprocesoru. Ale ani v QT nemaji kapacitu resit dlouholete BUGy.

Problem QT je zase v tom, ze se snazi byt chybejicim SDK pro C++ a nepokryvaji jen GUI, ale i vlakna, ODBC, soubory, ...

Kdybych dneska zacinal s GUI aplikaci pro Linux(anebo multiplatformi) tak bych asi pouzil FLTK. Anebo bych "ukradl" mikro-framework ktery ma MySQL Workbench. Ten vypada dobre a nativne na vsech platformach a neklade si cile, ktere neni mozne splnit.

[bindiff]

Qt oproti GTK+ vypadá jako (větší) SDK, protože pod názvem Qt máme nejenom qtgui, ale i další knihovny. GTK+ je název GUI toolkitu, který však staví na dalších knihovnách: GDK (low-level GUI – „vyrábění okýnek“), Cairo (kreslení), Pango (text), GStreamer (média), GIO (abstraktní I/O), atd. Pod tím vším stojí GLib, který je zhruba ekvivalentní qtcore z Qt. Oboje jsou relativně rozsáhlá SDK.

[xkucf03]

Anebo bych "ukradl" mikro-framework ktery ma MySQL Workbench. Ten vypada dobre a nativne na vsech platformach a neklade si cile, ktere neni mozne splnit.

Podle obrázků to vypadá, jako by měli vlastní abstrakci, která ve výsledku kreslí nativní GUI (GTK, Windows, Mac…).

[Kate]

Další problém je, že C++ se s pár výjimkama (třeba python má dobré bindingy) nedá moc použít z čehokoliv co není C++. GTK přes FFI slinkuju s C, C++, D, Rustem, Go, Valou...

Jo to je pravda. Ccko je porad ten nejvetsi spolecny jmenovatel. A da se pouzit se vsim. Na druhou stranu ale Ccko nema tridy a objektovy model a tak to nahrazuje makrama preprocesoru. A to uz je dost silenost. Takovy kod se tezko udrzuje.

Oproti tomu kombinace QT + Eclipse CDT nabizi pohodli, doplnovani jmen funkci a typovou kontrolu.

[xkucf03]

Oproti tomu kombinace QT + Eclipse CDT nabizi pohodli, doplnovani jmen funkci a typovou kontrolu.

Souhlas. S Qt a C++ se programuje dost pohodlně na to, že nevidím moc důvod, proč nad to patlat další mezivrstvu a psát to GUI v jiném jazyce. Když už člověk používá Qt, tak je nejlepší to psát rovnou v C++, protože mj. odpadnou problémy s těmi mezivrstvami, které to propojují s něčím dalším (chyby, nekompatibilita, chybějící funkce, pomalost atd.).

Pokud je zbytek programu v jiném jazyce, tak to ještě neznamená, že z toho jiného jazyka člověk musí/má vytvářet tlačítka, okýnka, obsluhovat GUI události atd. Je to otázka kudy vést řez (rozhraní) – už jsem o tom psal dřív v blogu. Ta GUI vrstva může být celá v C++ a ostatní kód v něčem jiném – a mezi tím relativně jednoduché rozhraní, které si navrhnu (ať už ve formě céčkových hlavičkových souborů nebo třeba nějakého protokolu).

[Kate]

Jako, už jsem v Qt dlouho nic nepsala, ale co si vzpomínám, v makro šílenostech je ten framework taky docela přeborník :)

To bejvavalo. Jeste to QT podporuje kvuli zpetne kompatibilite, ale od verze Qt5 se misto maker pouzivaji C++ sablony.

Dokonce kod (signaly) ktere se drive iniciovaly az za behu se ted iniciuji a predevsim kontroluji behem kompilace.

[..... Izak .....]

QT je na tom lepe, nebot ma NULOVOU kompatibilitu - dokonce je tam mechanizmus, ze ti zabrani aplikaci vubec spustit, proto mas v systemu vsechny verze QT co pouivas vzdy hezky ve svem adresari a promenou QT_HOME etc. uz si je vsechny nepamatuji si je prepinas pro kazdou apku vzlast ... kdysy to byl velky problkem, nebot stara paka zkousela nove QT a nechapala ze neni v QT - coz je lin na posledni, ale treba v QT2 - nebot prece predtim byla defualt tedy v QT ... dnes uz je to vice ostreno a pocita se s tim ... btw QT je lepsi toolkit o tom zadna, hlavne je to cely sitovy framework, lze v tom psat sitove aplikace, dokonce meli ambice porazit SAP s tim, ze prece QT bezi na vsem, vcetne mobilu a tabletu ... i proto na QT stavi KDE ...

BTQ GTK+ ma vice komponent ale tez je vlastne zpetne nekompatibilni a mas v OS vice verzi, jen ne kazdou zvlast, ale hezky v systemu a vola si bud 2,3,4 ...

QT vlasten sveho casu zar8izla Nokia kdyz koupila puvodniho vyrobce s tim, ze nejdrive ji zarizla, pak povolila jen pro free projekty - nebot hrozilo ze ji KDE forkne ... a dnes ani nevim, asi ji lze bez podpory pouzit i v komerni aplikaci - ale v te dobe kdy se to vyvijelo dost lidi sahlo na GTK+ - nebot tam tohle nehorzi, nebot je to cistye GNU projekt Gnome a GNU organizace ... tedy bude vzdy free

[lukve]

Mozno le taka teoreticka otazocka slo by s tou ich kniznicou skompilovat LXDE ?

[xkucf03]

Uvnitř se to pořád jmenuje GTK, GDK atd. tak počítám, že by to šlo. Akorát ta knihovna se nachází v repozitáři Ardouru, tak by sis ji musel odtamtud vykopírovat a udělat z toho samostatnou sdílenou knihovnu. To by právě bylo fajn, kdyby udělali oni (ale zase chápu, že je s tím víc práce udržovat to i pro ostatní).

[disorder]

Obavam sa, ze ich verzia nikdy nebude podporovat veci ako a11y, takze pre vseobecne pouzitie to nebude. Minule som dokonca videl hex editor, ktory vsetko vykresloval sam.