Qt 4.5 pod LGPL

Nokia oznámila, že Qt 4.5, ktorej vydanie je naplánované na marec 2009, bude možné používať aj pod Lesser GPL 2.1. Komentáre k udalosti je možné nájsť napr. na dot.kde.org a arstechnica.com.

14.1.2009 10:00 | andree | Komunita

Komentáře

[andree]

In your face, Gtk! :-)) no.. ale som zvedavy, co s tym bude robit najblizsie roky Gnome...

[Let_Me_Be]

Kdyz jsem si dnes tuhle vec precetl na webu Nokie tak jsem skoro dostal infarkt Bomba, prave jsem si chtel poridit jednu komercni licenci na Qt.

[mikro]

Hej, je to celkom fajn tah, ja by som si strasne prial, aby raz uvolnili aj Qt Visual Studio Integration ako samostatny produkt, aj ked je mi jasne, ze to by si Nokia asi podrezala konar, pretoze potom by si uz Qt Commercial asi malokto kupil za tych 2999 Eur

 

Na druhu stranu, ak ma clovek spravene qmake projekty a neboji sa trochu programovania, tak tu VS integraciu az tak nepotrebuje.

[Petr]

Opravdu by autora zabilo, kdyby jednou větou napsal, co to prakticky znamená? Takovéhle zprávičky jsou naprd, to aby člověk 5min následně klikal

[Jary]

Co jsi se tedy dozvěděl, že to znamená?

[xzavrel]

Můžu se zeptat, co to tedy znamená? Je tedy možné používat nyní Qt pro komerční projekty bez nutnosti dát všanc zdrojové kódy a nemusím mít commercional licenci? Zrovna jsme uvažovali, že nějakou koupíme.

[andree]

ano, pokial neupravis Qt a budes s nim linkovat svoj sw dynamicky (=Qt bude distribuovane v podobe .dll/.so suborov)

[Spike]

 Pokud upravíš Qt, tak musíš distribuovat jen změny, které jsi provedl v Qt, ne?

[Deleted [8409]]

Otázka je, jaký je v tom rozdíl

[Spike]

 V čem? Pokud by bylo Qt jen pod GPL, tak bys nemohl udělat produkt s uzavřeným zdrojovým kódem (když odmyslím komerční licenci, která stojí $$$), který by byl na Qt založený. S LGPL takový produkt udělat (a distribuovat) můžeš (aniž bys kupoval komerční licenci). Jen změny Qt musíš distribuovat taky.

[Deleted [8409]]

To vím

Reagoval jsem na to, jestli po změně Qt distribuovat celé Qt včetně změn nebo jen ty změny (patch).

Podle mě do Qt stejně nikdo rýpat nebude

[Spike]

To nevím, na co jsi reagoval, protože o distribuci Qt jsem nic nepsal. Psal jsem o nějakém uzavřeném programu, který je založený na knihovně Qt. A třeba autoři toho uzavřeného programu Qt nějakým způsobem upraví, vylepší, aby ten jejich program s Qt fungoval – pak budou muset v duchu LGPL tyto změny Qt distribuovat společně se svým programem. S komerční licencí si ty změny mohou nechat pro sebe a ke své aplikaci přibalit jen binárky svého upraveného Qt.

Asi jsem se nevyjádřil jasně, nevím.

[mikro]

No to znamena, ze doteraz ak chcel sirit tvoju aplikaciu do sveta a bola postavena na Qt, tak si musel dodat aj jej zdrojaky, co bolo pre komercnu sferu dost nepouzitelne. Takze jedina cesta bola licencia za cca 100 000 SK za full Qt Commercial.

Teraz mozes zobrat Qt, zlinkovat s Qt a nikto ta nenuti zdrojaky releasnut.

[stick]

Znamena to este jednu obrovsku vyhodu. Je mozne linkovat kod, ktory je napr. pod MPL, EPL a inym OSS licenciami s Qtckami. Mozno sa dockame Qt UI pre Eclipse, Qt Firefoxu atd.

[Espinosa]

Firefox už byl portován pro Qt dávno, a to dokonce hned (minimálně) dvakrát!
http://dot.kde.org/1094924433/ - KDE Akademy 2004
http://arstechnica.com/news.ars/post/20080818-nokia-helps-port-firefox-to-qt.html (2008)

Vývojáři Firefoxu se nadále budou držet Gtk (GDK přesněji), mají v tom spoustu know-how zato málo důvodů přejít. Ono je sporné jestli Firefox je vůbec Gtk/Gnome aplikace, používá nějaké nízkoúrovňové Gdk rutiny pro vykreslování, jak pro canvas tak pro UI, proto bylo FF tak relativně jednoduché portovat. Tuším že se to povedlo dokonce za jeden den.

V licenci není a nebyl hlavní problém, nejsou lidi co by port udržovali a rozvíjeli.

S Eclipse se to má tak, že KDE SWT binding byl plánován dávno, licence opět nebyla problém (určitě ne pro IBM která za rozvojem SWT primárně stojí) nejsou lidi, rozpočet, dobrovolníci, vůle. Portovat SWT je nepoměrně komplexnější záležitost než portovat FF.

[Bambus]

Konecne nekdo NORMALNI.To to neslo takhle napsat rovnou ? :o)

[xindl]

Věštím věštím, GNOME přejde do pěti let na QT knohovnu do deseti let zanikne, nebot si uvědomí proč vlastně Gnome vzniklo a že už není žádný objektivní důvod vyvíjet ho dále, Gimp, inkscape přejde do 5ti let též na QT a  GTK zhyne bídnou smrtí.... )))

[Deleted [8409]]

Ty toolkity už tady jdou příliš dlouho, nezanikne asi ani jeden. Nové projekty se možná začnou psát v Qt, ale staré projekty zůstanou. Přechod GNOME na Qt by navíc byla ostuda

Kdyby tak Trolltech tento správný krok udělal dřív... :)

[xindl]

 

 

...Kdyby tak Trolltech tento správný krok udělal dřív... :)....

tak to máš samožřejmě pravdu. ale víš jak. Boží mlýny melou pomalu  ale jistě. Já si od tohoto kroku konkrétně slibuji že KDE bude více preferovanej desktop než GNOME u komerčních firem.

[andree]

to dufam aj ja - ze ubuntu zacne viac riesit KDE napr.

[Daniel Kvasnička ml.]

to dufam aj ja - ze ubuntu zacne viac riesit KDE napr.

Pak ale nechapes, proc Ubuntu preferuje GNOME. S licenci to nema moc poslecneho, jde o filosofii desktopoveho prostredi, kterou GNOME razi.

[andree]

to je fakt, no.. na druhej strane, KDE zase take zlozite na ovladanie nie je - myslim ze nejaky KDE4.8 by mohol byt celkom vaznym kandidatom na UI aj pre BFUs... on je imo aj teraz - aj ked je pravda, ze miestami dokaze zmiast aj mna :o)) na druhej strane malokedy ma nastve tak, ako ked sa mi objavi napr. gnome print dialog )) No, ale to uz je iny flame :)

[Daniel Kvasnička ml.]

a druhej strane, KDE zase take zlozite na ovladanie nie je - myslim ze nejaky KDE4.8 by mohol byt celkom vaznym kandidatom na UI aj pre BFUs...

Dalsi hloupy predpoklad ...bohuzel neprijemne casty. Mas pocit, ze kdyz je GNOME minimalisticke, ze to znamena, ze je urceno pro BFU. Nikoliv, je urceno pro lidi, kteri maji jine naroky na nastavovani sveho pracovniho prostredi. To same plati o Mac OS X, kterym se GNOME celkem nepokryte inspiruje. OS X pouziva nemale procento vyvojaru (vcetne tech vyvijejicich primo pro OS X) -- takovi lide maji prece k BFU daleko a presto jim ta jednoduchost vyhovuje.

[andree]

ee, tiez mam rad minimalizmus, ale nie za kazdu cenu (a idealne je mat moznost nastavit aj detaily, ked uz clovek chce) - ja mam pocit, ze k takemu niecomu KDE4 smeruje, uvidime casom..

ad OS X - o tom by sa tiez dalo diskutovat - ja som mal miestami chut rozbit klavesnicu o tu mini kocku na stole, ked som to nedavno skusal :)) asi 5 minut mi trvalo najst system settings, safari mi tiez moc nesadlo, k itunes som sa nastastie nedostal :)) naproti tomu ked som videl KDE, tusim v2, prvykrat, vedel som celkom intuitivne, kde co je.. holt.. ale ako pises, to je asi o ludoch :o)

[bhy]

naproti tomu ked som videl KDE, tusim v2, prvykrat, vedel som celkom intuitivne, kde co je

to ale mohlo být kvůli podobnosti s windows.

[frEon]

jj, je to o idividualni. Ja kdyz jsem cca rok (2003-2004) pracoval s osx tak mi taky neustale tekly nervy.

[Spike]

 Eh, 5 minut hledat systémové nastavení, když je „hned“ v tom „hlavním menu“, případně můžeš použít Spotlight? To asi nebude chyba v systému… Na Safari nesedlo co? Ovládá se jako jakýkoli jiný standardní webový prohlížeč (a na rozdíl od Opery se v něm třeba dá i prohlížet Web). Napadá mě snad jen „nemožnost“ maximalizovat okno, což vytáčelo i mě, ale nakonec je to v podstatě fuk. iTunes jsem ze začátku neměl vůbec rád, nicméně nakonec jsem si rozhraní celkem oblíbil (hlavně nový cover view ve verzi 8). Nejvíc mi chybí nativní podpora Vorbis a FLAC, méně pak nějaká fronta (dočasný playlist) a asi i možnost poslechnout si hudební soubory bez jejich přidávání do knihovny (když zkouším něco nového a nevím, jestli to hned nepůjde do koše).

Když to shrnu kolem a kolem – ať používám Windows, Mac OS X nebo Linux s KDE nebo s Gnome – všude najdu věci, které se mi líbí, a věci, které mi chybí nebo mě vytáčejí.

[bhy]

a na rozdíl od Opery se v něm třeba dá i prohlížet Web

tak to teda rozveď. v opeře se nedá prohlížet web? jsme vadní, my co nám to jde?

[Neel]

Myslím si, že Gnome je pro začátečníka mnohem lepší než KDE. KDE má poměrně obsáhlé menu, kde se lehce mohu stratit.

[...............23]

Bullshit

 

 

To že niektorí ľudia preferujú Gnome pred KDE sa dá pochopiť, ale tie uvádzané dôvody sú proste smiešne. Imho väčšina ľudí ho používa lebo sú na neho proste zvyknutí, pre nič iné...

[multi]

ubuntu pouziva gnome, protoze ma stejne dlouhy vyvojovy cyklus

[AHAHA]

To by KDE ale muselo trochu zmenit pristup ... :/

[trekker.dk]

já si od tohoto kroku konkrétně slibuji že KDE bude více preferovanej desktop než GNOME u komerčních firem.

Copak je nějakej důvod pro to, aby tomu nebylo už teď?

[AHAHA]

Co do verze 3.5 - chybi podpora do budoucnosti, bez vyvoje

Co do verze 4.X - stale jeste prekotny vyvoj, nestabilita, chybi programy (nutnost mit i KDE3 knihovny), trochu jine zamereni vyvojaru (prvnich pet polozek v oznameni noveho vydani je vzdy seznam novych efektu) ...

[trekker.dk]

Co do verze 3.5 - chybi podpora do budoucnosti, bez vyvoje

Stabilní, ozkoušené a odladěné prostředí, udržovat se ještě nějakou dobu bude - pro firmy docela ideální.

[AHAHA]

Udrzovat se nebude - mozna tak budou opravovat kriticke bugfixy, ale to je tak vsechno ...

Firmy jsou sice vetsinou konzervativni, ale ne v tom smyslu, ze chteji pouzivat 10 stejnou verzi ... (bude se pro KDE3 backportovat podpora treba pro nove formaty souboru, protokoly apod?). Firmy maji nejradsi to, co se deje s Gnome - pomaly, nenasilny vyvoj, vzdy zpetne kompatibilni bez revoluci.

[Espinosa]

Gnome2 přerušilo zpětnou kompatabilitu stejným způsobem jako u KDE 3 na 4. Aplikace se museli přepisovat, a trvalo to dost dlouho.

Mám to ještě v živé paměti, byl jsem early adopter, zkompiloval jsem si Gnome 2.0.0 hned jak vyšlo (2002 tuším). Zlákala mě hlavně podpora AA fontů. Jaké bylo moje zklamání když po spuštění byla Gnome 2 aplikace leda tak gedit. Všechno ostatní co jsem používal - Gnome Commander, xmms, gmplayer - zůstali gnome1/gtk+ ještě dlouho, někdy i roky poté. Dokonce i Gimp (asi dva roky tuším).

Naproti tomu mě mile překvapila rychlost adopce KDE4 - Digikam, Amarok, Krusader, Kopete, Konqueror, Gvenview, Kdenlive. Skoro všechno už má verzi pro nové prostředí nebo je těsně před dokončením (RC a použitelné betaverze), pravda, kvalita je kolísavá. Chybí mi snad jen Kaffeine. Vezmeme li v úvahu, že až KDE 4.2, které ještě nevyšlo, je označeno tvůrci KDE jako skutešné KDE4, určené pro širší nasazení, je rychlost adopce přímo raketová.

Oba desktopy mají stabilní API po dlouhou dobu, tady nevidím problém. O úspěchu v komerční sféře rozhoduje kvalita verze pro Windows, případně OS X, protože top jsou jediné platformy kde kouká pro desktopou aplikaci nějaký zisk ;)

[Espinosa]

Aplikace se musely ..už to vidím a opravit to po odeslání nelze, grrr

[s0]

Přesně. Hlavně ta doba, než asi 307x odkládané gnome 2 bylo opravdu vydáno...

Navíc to G2.0 byla snad ještě větší zoufalost než K4.0

[Radek Miček]

Problém je, že pro knihovnu Qt existuje strašně málo bindingů do jiných jazyků.

[Deleted [8409]]

A jaké jazyky vám konkrétně chybí ?

[Radek Miček]

Například OCaml, Erlang, Haskell...

[Ladicek]

No, ehm, dobře ) Ale s těmito jazyky začínat výtku na adresu Qt slovy problém je, to je dost odvážné

[Radek Miček]

No dobře, pro mnoho lidí to asi problém nebude.

Na druhou stranu je dost těžké udělat slušný binding pro jazyky bez objektů pro tak velkou knihovnu jako je Qt. Zde má Gtk navrch.

[martyone]

A že zrovna Haskell je jeden z těch co Qt bindings mají[1]

[1] http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries#qtHaskell

[Radek Miček]

Podívejte se do dokumentace, já bych v tomhle programovat nechtěl

Podívejte se třeba na qthaskell.berlios.de/doc/apiguide/Qtc-Gui-QWidget.html a na qthaskell.berlios.de/doc/apiguide/Qtc-Gui-QPushButton.html. Jsou tam funkce qWidget_setVisible a qPushButton_setVisible. Ačkoliv by bylo jistě vhodnější mít jenom jednu fci jak pro QWidget tak pro QPushButton. Podobných příkladů najdete spousty.

Gtk2Hs ač není perfektní, je momentálně mnohem příjemnější na používání.

 

[thingie]

Říkat dokumentace prostému výpisu funkcí s haddockem, no, já nevim.

[Luboš Doležel (Doli)]

To jsou strašně moc používané jazyky

[AHAHA]

V akademickem prostredi ano.

[Ladicek]

Tam zase nepotřebují GUI

[Luboš Doležel (Doli)]

Jakoby na tom záleželo Zatím jsem nenarazil na jediný OSS program dělaný v těchhle obskurnostech a nevím ani o firmě, kde by to používali.

[stativ]

Erlang je použitej ve Wings3d.

[Ladicek]

No, zrovna Erlang je občas vidět. Jak se různě rojí takové ty škálovatelné databáze pro web, všechno je to v Erlangu (třeba CouchDB nebo Scalaris, spekuluje se o tom, že Amazon SimpleDB taky). Ty Wings3D, zmíněné vedle, když jsem prvně viděl, tak jsem skoro nevěřil vlastním očím Ale pokud vím, je to spíš výjimka.

[AHAHA]

Mozna se jen nepohybujes v tech spravnych kruzich ...

(Kam nedohlednu, to neexistuje?)

[Luboš Doležel (Doli)]

Neříkám, že to neexistuje, jen je to v "softwarovém ekosystému" zcela nevýznamné.

[Radek Miček]

Až na to, že mainstreamové jazyky čerpají nápady z těchto okrajových jazyků.

[Ladicek]

No, tak já bych řekl, že Erlang je přibližně stejně nevýznamný, jako Ericsson. Haskell zase docela podporují v Microsoftu jako zdroj novinek pro C# (a vypadá to, že F# se poslední dobou taky rozmáhá).

[David Jaša]

ejabberd

[xm]

V Erlangu myslím běží třeba celý Chat (IM) na Facebooku. To při milionech lidí kteří Facebook využívají není zrovna málo Postaven je na něm i nejlepší/nejpoužívanější/nejoblíbenější Jebber server ejabberd. Ono se není co divit, na takovéto distribuované serverové aplikace je Erlang nepřekonatelný.

Nicméně to nic nemění na to, že na psaní GUI by to rozhodně nebyl vhodný nástroj, takže bindingy na Qt by byly IMHO nesmysl.

[trekker.dk]

Qt taky nemá bindingy pro Brainfuck, Whitespace, Intercal... Ono je vlastně úplně nepoužitelné...

[AHAHA]

Srovnavat Haskell s Whitespace ... (aneb nemamli argumenty, jednoduse zabehnu do extremu ...)

[trekker.dk]

Tím jsem chtěl poukázat na to, že četnost využití těchto jazyků je přibližně stejná, tedy zanedbatelná oproti C#, C++, Javě,...

(Ano, je mi naprosto jasné, že tyto jazyky jsou oproti Haskellu, Erlangu a podobným naprosto podřadné a jenom neschopnost programátorů přejít na tyto dokonalé jazyky brání jejich rozšíření.)

[AHAHA]

jenom neschopnost programátorů přejít na tyto dokonalé jazyky brání jejich rozšíření

To netvrdim, sam je moc nepouzivam, ale IMHO sve misto a vyuziti maji ...

[xm]

Jistě, mají, Erlang je na některé (serverové) aplikace nepřekonatelný a také se na ně zhusta používá (v produkčním prostředí). Nicméně GUI mezi tyto věci nepatří, bindingy na Qt by tedy byly IMHO zbytečností.

[andree]

hmm, c++, c#, python, perl, java, javascript, ruby.. co konkretne ti este chyba?

[andree]

a pozeram ze su aj pre haskell, php

[Radek Miček]

Například zmiňovaný binding pro Haskell je neelegantní a prakticky nepoužitelný.

Srovnejte si to například s bindingem Gtk2Hs -- to je úplně něco jiného.

[changeit]

mozete mi prosim postkytnut nejaky link na bindings pre C# ?  pretoze ja som povacsinou narazil na mrtve projekty...

[andree]

qyoto... aktualne je to su c# bindings na rovnakej urovni ako pre ostatne jazyky (odkedy to 'riesia' cez libsmoke) - vid websvn.kde.org/trunk/KDE/kdebindings/csharp/ ... napr. v ubuntu su na to priamo baliky, kazdopadne skompilovat to zo zdrojakov to tiez nie je (az taky) problem... uz ina vec je, ako to funguje v mrkvosoftackom .NET, to mozno bude vacsi problem rozbehat (na win32)... v Mono mi to ale fungovalo celkom spolahlivo, kym som to skusal...

[Tapan]

Blázne. Spíš vznikne další knihovna, které si bude klást za cíl vzít si to nejlepší z QT a GTK, pak další dvě odštěpené knihovny, které budou mít stejné cíle, ale půjdou si svou cestou z licenčních či ideologických důvodů, a alespoň jedna další odštěpená knihovna vedená někým, kdo se někde s někým pohádal a odmítl dál s původním týmem spolupracovat

[xindl]

)))

[stativ]

U Gimpu je to nepravděpodobné, vždyť ho sami vymysleli. Proč si myslíte, že se to jmenuje GTK?

[xindl]

tohleto dávno vim. )

[Deleted [8409]]

Já jsem myslel, že to G znamená GOD

[stativ]

Ja vim, on vi ty pico.

[xindl]

))

[Daniel Kvasnička ml.]

Zrovna u Inkscape by byl port na Qt uzasnou zpravou, jelikoz by pak bylo mnohem jednodussi udelat "nativni" verzi pro Mac OS X. U GIMPu bych spis byl radsi, kdyby od nej utekli vyvojari k Seashore

[andree]

alebo ku krita-e...

[Spike]

 V čem je problém? Nativní port Gtk+ pro Mac OS X existuje (ačkoli je mnohem mladší, než port Qt pro OS X).

[Daniel Kvasnička ml.]

Teda ty mas hodne volny vyklad pojmu "nativni" Krome vzhledu jsou to v prvni rade klavesove zkratky, kde ocekavam, ze se bude aplikace chovat v zakladnich ukonech tak, jako kazda OS X aplikace. Nemluve o tom, ze "nativni" GTK pro OS X stale nepouziva menubar, pokud vim. Plus je samo o sobe porad experimentalni veci, ne? Proste je tu jedno ale vedle druheho...

Na prikladu Skype nebo Last.fm playeru je videt, ze se da Qt hodne hezky vytunit pro OS X, takze by to prospelo i Inkscape.

Po ocku sleduju VectorDesigner, jak se vyviji. Ten je Inkscapu asi nejblize, pokud jde o nativni OS X apps.

[Spike]

 Říkám, že je mnohem mladší ten port.  Na ty klávesové zkratky by měl být patch a Gimp s nativním (ne-X11) GTK+ používá menubar…

VectorDesigner mám, ale nemůžu říct, že by mi vyhovovalo jeho ovládáni, Inkscape mi přišel intuitivnější.

[multi]

to by uz debian davno presel na rpm balicky

a ruznorodos u open source vzdycky bude

[xindl]

tímto krokem totálně padá poslední vítka GTK vývojářů, na adresu svobody licencování. Takaže tedka zůstává pouze jejich ego že by se musel iučit něco lepšího a oni prostě umí jenom GTK. ))

[Let_Me_Be]

IMHO je ideologicky boj C vs C++ mnohem hlubsi nez byl LGPL vs GPL.

[andree]

a to je dost divne, pouzivat pure-C kniznicu, ked jednym z najbeznejsich prikladov pre vyuku "objektoveho programovania" su UI objekty... :o)) ale tak ked sa niekomu chce pisat <code>gtk_do_this_with_that(a, b, c)</code> miesto <code>object->do_this(c)</code>, preco nie... ale ak potom clovek pouziva napr. Gtk++, to uz potom vobec nechapem, naco je to dobre :o)

jedina nevyhoda toho Qt mozno moze byt build system a qt preprocessor - aj ked mne to nepride byt az taky zly obchod za featury, ktore cloveku z toho plynu...

[Kvakor]

Jestli si to dobre pamatuju, tak sice prime pouziti v neobjektovem jazyce moc elegantni neni, ale v pripade bingingu do jinych jazyku je delat konverzi z jednoho systemu objektu do jineho (na urovni knihovny) mnohem slozitejsi nez prevadet pseuobjekty v neobjektovem jazyce na prave objekty.

[Jury]

Přesně tak. Nějakou dobu jsem se rozmýšlel, jestli používat Gtk+ nebo Qt. Nakonec zvýtězilo Gtk, jelikož má mnohem použitelnější binding do jiných jazyků. Já konkrétně programoval v Ruby a nyní C# (mono), a v těch je ten rozdíl hodně velký. A to ani nemluvím o (mizerné či neexistující) dokumentaci.

[Non_E]

Když mi to přišlo mailem, tak jsem si myslel, že se jedná o phishing

Neznamená to, že by se pro eclipse mohlo použít na gui qt?

[Nikola Ciprich]

jiste... hned jak to nekdo naprogramuje ;)

[frEon]

WOW. Tak to jsem vazne necekal. A radost mi to udelalo.

[dad]

takze necht je dan vektor objektu v Qt, - jak je definovan ?

do toho vektoru se zapisi pres new vytvorene objekty, Buttony, Labely apod.

Jak vypada prikaz, kdy kreslim nejaky objekt na souradnici x,y  , objekt[i]->set_X()  nemohu pouzit, nebot C++ rve, abych pouzil cast.

[trekker.dk]

takze necht je dan vektor objektu v Qt, - jak je definovan ?

std::vector<QWidget *> objekt;

do toho vektoru se zapisi pres new vytvorene objekty, Buttony, Labely apod.

objekt.push_back (new QLabel(QString::fromUtf8("Kecy v kleci"), this));
objekt.push_back (new QPushButton(QString::fromUtf8("Tlačítko"), this));

Jak vypada prikaz, kdy kreslim nejaky objekt na souradnici x,y , objekt[i]->set_X() nemohu pouzit, nebot C++ rve, abych pouzil cast.

objekt[0]->move(500,340);
objekt[1]->move(500,300);

Jenom jedno z možných řešení, další variantou je třeba QList<QWidget *>

Je smutné, že dnešní neschopná mladá generace lidí, kteří ani neumí programovat, musí radit té tvojí moudré a mnohem schopnější generaci, jak udělat něco tak jednoduchého, jako bylo tohle.

[diskie]

nuz, toto sa dalo cakat ! super! dufam, ze to nie je 1. april

[dad]

na netu se pise, ze nebude zadna vyjimka pro staticke linkovani, to je u LGPL tak trochu nesikovne, ze se musi nabizet i ty objekty a navody pro linkovani. Ale porad lepsi, nez zdrojaky....

[xm]

Spolu s již dříve uvedeným QGtkStyle (viz zprávičky 1, 2) je útok na GTK dokonán, muhahaha [ďábelský smích].

Prorokuji GTK pomalý ústup (pomalý proto, že přecijen GTK programů je hromada a stále je tu GNOME... i když první vlaštovky přechodu na Qt tu již byly - třeba VLC nebo Avidemux), GTK nemá již naprosto žádné výhody, jen nevýhody (někdo by mohl namítnout C vs. C++, ale v případě GUI toolkitu je C oproti C++ velkou nevýhodou, ať se to zarytým Cčkařům líbí nebo ne).

[Jan Drábek]

A mě zrovna začalo líbit

[Drew]

No, vlc bylo předtím pod wxwidgets, ne přímo gtk a avidemux má teď jenom qt navíc a gtk opřád zůstává, ne?

[Ilfirin]

Jj, ale kdo chce svět vidět jedním způsobem, uvidí ho jedním způsobem .

[xm]

Ano, to ale nic nemění na faktu, že aplikace, které měly pod Linuxem pouze GUI založené na GTK (wxWidgets používá pod Linuxem jako backend GTK), nyní buď přešly na Qt nebo alespoň nabízejí Qt jako alternativu.

A to je rozhodně viditelný posun dopředu. Víš snad o nějaké alespoň trošku známější aplikaci, kde by to bylo naopak (přešla z Qt nebo wxWidgets na čisté GTK)? Já tedy nikoliv.

Používat obezličky jako wxWidgets nebo gtkmm (protože čisté GTK je neobjektové a těžkopádné) ztrácí smysl, když je tu komplexní a multiplatformní Qt, které má vše co je potřeba (ba dokonce mnohem více ).

[J. M.]

i když první vlaštovky přechodu na Qt tu již byly - třeba VLC nebo Avidemux

Avidemux nikdy na Qt nepřešel (ani o to nikdy neusiloval). Jenom to přidal jako další možnost.

[J. M.]

Joj, měl jsem si před svojí reakcí přečíst těch pár příspěvků výš.

[David Watzke]

Úžasný. Nikdo nechápal, když jsem si to ve škole přečetl na mobilu a začal najednou jásat

[pepik]

+1 Stejná reakce ve stejném prostředí :D

[Radek Podgorny]

Qt 4.5 will also be available under commercial licensing terms, while licensing for previous versions of Qt remains unchanged. In addition, service offerings for Qt will be expanded to ensure that all Qt development projects can have access to the same levels of support, independent of the selected license.

...tim padem dusledkum asi moc nerozumim. Co se jako meni?

[Andrej Herceg]

Snáď sa potom nájde niekto, kto Qt opraví tak, aby to bolo použiteľné aj bez hardvérového urýchľovania vykresľovania aspoň tak, ako staré verzie (a možno sa prestanú objavovať príspevky, že za všetko môže Nvidia). ;)

Alebo je to pomalé vykresľovanie spôsobuje KDE4 (KDE 4) a nie Qt?

[Luboš Luňák]

http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/

[paskma]

Výborná zpráva. Konečně bude Qt v mých očích konkurenceschopná. Opravdová konkurence pro Gtk.

[stick]

http://www.youtube.com/watch?v=IsTIIQocSqs

[decumanus]

To musí mít radost lidi, co si před týdnem koupili licence... Nic ve zlém.

[s0]

inu, takový drivery pro Oracle, DB2, atd. a hromada dalších widgetů bude stejně v placený verzi...

[borgcube]

no este je tu jedna nevyhoda pre Qt. 90 % robim v C++ a Qt mierne modifikuje tento jazyk kvoli singalom a inym veciam. kdezto GTKmm si vystaci zo standardnym C++, bez modifikacii.

[Luboš Luňák]

Qt programy jdou prelozit primo C++ prekladacem a tedy si take vystaci se standardnim C++.

[Deleted [8409]]

Zkuste si porovnat přístup libsigc++ a Qt. V přístupu Qt vidím hodně výhod. Od introspekce až po podporu skriptování a vytváření signálů dynamickou cestou např. z XML. Další věc je ta, že použitím libsigc++ vám pro každý signál/slot roste velikost instance trídy.

[Luboš Luňák]

Další věc je ta, že použitím libsigc++ vám pro každý signál/slot roste velikost instance trídy.

Opravdu? Tak to je asi dost dobry duvod[*], proc to Qt potom nikdy takhle delat nebude. Zrusit si zpetnou kompatibilitu kazdym signalem/slotem by dopadlo hodne spatne.

[*] Krom tech vsech ostatnich duvodu, samozrejme.

[Luboš Doležel (Doli)]

V čem má spočívat ta nevýhoda? Navíc se nemodifikuje jazyk - je tam pár maker a program moc, který generuje obalující kód pro sloty.

[Ladicek]

Někteří prostě mají (z mně neznámého důvodu) značnou apriorní nedůvěru v ten preprocesor (moc). No, objev generování kódu takové lidi nejspíš ještě čeká

[Luboš Luňák]

Terminologicka: Moc neni preprocesor, je to generator kodu. Preprocesor je neco, cim se musi prohnat data (=zdrojak) predtim, nez se to da dale pouzit (proto se to jmenuje pre-procesor). Zdrojovy kod Qt/C++ se preklada primo C++ prekladacem (kde se na nej pred vlastnim prekladem pouzije C++ preprocesor, ale na to si snad nikdo stezovat nechce :) ?).

[Ivan]

jj, moc je spis generator kodu. Prepocosor je CPP na kterym je zalozany GTK. Zneuzivani maker preprocesoru je zlo, ktery snizuje citelnost kodu a ladeni. Kdyz pouzivate preprocesor tak mate problem v tom, ze kod ktery vidite na monitoru neodpovida tomu co zpracovava kompilator a k cemu existuji debug symboly. Pokud pouzivate Moc, tak mate pristup z mezivysledku(c++ zdrojaku) a muzete porovnat tenhle zdrojak s tim vidite v gdb.

[Ladicek]

On každý preprocesor je v podstatě generátor kódu , a i cpp vám dá (mezi)výsledek, když chcete. Já vidím rozdíl mezi mocem a cpp jediný: fungování cpp je popsané přímo v definici jazyka, zatímco moc je jakási neznámá síla zvenčí (OK, máme zdrojáky, ale stejně). Jak moc, tak cpp operují nad lehce okořeněným normálním Céčkovým/C++kovým zdrojákem, proto bych je označil za preprocesory; generátor kódu obecně může blejt C++ třeba z XMLka.

[Luboš Luňák]

Jenze ne kazdy generator kodu je preprocesor :).

[Michal Vyskočil]

No hlavní rozdíl mezi cpp a moc je v tom, že bez prvého se není možné obejít, protože samotný jazyk nic takového jako #include a #define prostě nenabízí. Kdežto bez moc se obejít lze, ale je otravné ten kód, který generuje, psát ručně. Takže bych jej přirovnal k idl, což je generátor kódu jak vyšitý a nikdo mu, pokud vím, neříká preprocesor.

Takže cpp == nutnost, moc == pohodlnost.

[Ladicek]

Jak to, že bez cpp se nedá obejít? Dá se psát úplně bez něj, #include vyřeším duplikací kódu, #define "konstantní" proměnnou, podmíněný překlad rozsekáním do samostatných souborů… Nebo můžu použít úplně jiný makroprocesor nebo šablonový systém. Jako správný zvrhlík si dokážu představit namísto cpp používat třeba Velocity

Jinak mezi kompilátory různých IDL a mocem žádnou velkou paralelu nevidím. Ostatně je mezi nimi taky ten rozdíl, který jsem zmiňoval výše: IDL je zcela samostatný jazyk, který má tu smůlu, že se kompiluje do jiného vysokoúrovňového jazyka, zato moc (i cpp) bere trochu ošperkovaný C++ kód a generuje zase C++ kód.

[Ladicek]

Na druhou stranu, je fakt, že moc AFAIK musí rozumět syntaxi C++, což cpp (skoro) nemusí. Asi jste mě překecali

[Luboš Luňák]

Ten rozdíl je v tom, že když už věci jako #define použiju, tak cpp pak musím použít (nebo tedy třeba úplně jiný makroprocesor nebo šablonový systém, když si chceme hrát na pedanty). Jenže Qt zdroják s Q_OBJECT, connect() atd. půjde použít, i když se na moc ani nesáhne (jen se člověk bude muset dost nudit, aby si ten kód navíc tedy napsal ručně). To je ten rozdíl, proč Qt je pořád normální C++ (minimálně stejně jako Gtk je C).

[Michal Vyskočil]

#define "konstantní" proměnnou

Nemyslím, že je #define sémanticky shodné s konstatní proměnnou .

Nebo můžu použít úplně jiný makroprocesor nebo šablonový systém. Jako správný zvrhlík si dokážu představit namísto cpp používat třeba Velocity

To samozřejmě můžeš, ale to nemění nic na tom, že při použití jakéhokoli takového systému přidáváš do C/C++ něco, co ten jazyk sám o sobě neumí. Kdežto moc generuje C++ kód, který je prostě jenom pohodlnější generovat automaticky.

Jinak mezi kompilátory různých IDL a mocem žádnou velkou paralelu nevidím. Ostatně je mezi nimi taky ten rozdíl, který jsem zmiňoval výše: IDL je zcela samostatný jazyk, který má tu smůlu, že se kompiluje do jiného vysokoúrovňového jazyka, zato moc (i cpp) bere trochu ošperkovaný C++ kód a generuje zase C++ kód.

Představ si, že autoři zvolili pro IDL trochu ošperkovaný C++ jako výchozí jazyk a paralela je snad evidentní

[stativ]

#define "konstantní" proměnnou

Nemyslím, že je #define sémanticky shodné s konstatní proměnnou .

Přesně. Tohle mi připomíná velice vtipný kód vigry, se kterým se teď babrám, protože ho inteláckej kompilátor zřejmě prostě nezkompiluje tak, jak má:

#define VIGRA_SPECIALIZED_CAST(type) \
    template <> \
    struct RequiresExplicitCast<type> { \
        static type cast(float v) \
            { return NumericTraits<type>::fromRealPromote(v); } \
        static type cast(double v) \
            { return NumericTraits<type>::fromRealPromote(v); } \
        static type cast(type v) \
            { return v; } \
        template <class U> \
        static type cast(U v) \
            { return static_cast<type>(v); } \
 \
    };

VIGRA_SPECIALIZED_CAST(signed char)
VIGRA_SPECIALIZED_CAST(unsigned char)
VIGRA_SPECIALIZED_CAST(short)
VIGRA_SPECIALIZED_CAST(unsigned short)
VIGRA_SPECIALIZED_CAST(int)
…

Tohle přepisovat bez použití #define by byla spousta zbytečné práce a konstantní proměnná by se na to použít opravdu nedala.

[Ladicek]

To samozřejmě můžeš, ale to nemění nic na tom, že při použití jakéhokoli takového systému přidáváš do C/C++ něco, co ten jazyk sám o sobě neumí. Kdežto moc generuje C++ kód, který je prostě jenom pohodlnější generovat automaticky.

Oba programy generují C/C++, tudíž se lze obejít bez nich. A kde je hranice? Pokud vezmu to porozumění syntaxi "hostitelského" jazyka, jak jsem psal výše, tak souhlasím, že moc je generátor kódu a ne preprocesor.

Představ si, že autoři zvolili pro IDL trochu ošperkovaný C++ jako výchozí jazyk a paralela je snad evidentní

Tohle nežeru, IDL není programovací jazyk a nepotřebuje být turingovsky úplný

[06078]

Wow super zpráva. Ikdyž jsem to trochu čekal (no spíš doufal jsem v to), když Nokia otevírá i Symbian.

[Eregon]

Symbian bude open? To mi nějak uniklo. Ale radost z toho mám, i když na druhou stranu si nejsem jistý, že si Symbian vytvoří dost velkou vývojovou komunitu, aby se to nějak výrazněji projevilo (teď momentálně je pro mě Symbian nechutný nestabilní paskvil, jehož cílem je být chytřejší, než uživatel).

[06078]

Ano Nokia koupila všechny akcie a chystá se ho otevřít. Píše se, že by to mělo být do roku 2012, ale kdo ví. Byla tu i zprávička.

[Grunt]

Když to tak čtu, tak mě napadá otázka: A co je na GTK tak hnusného, že by měl zemřít strašlivou, pomalou a bolestivou smrtí a na GNOME tak strašného či zeleného, že už by radši měl shnít v kompost na místním poli? Samozřejmě teda z uživatelského pohledu(, ale když už nebude žádný uživatelský pohled, tak si vystačím i s nějakým jiným). I kdyby KDE nahradilo výchozí prostředí ve většině distribucí a ještě mi za něj zaplatili, tak bych si to stejně přeinstaloval mnohem radši na GNOME, protože mi přijde téměř dokonalé(tím samozřejmě neříkám, že je KDE špatné. A to říkám po dvou letech používání KDE 3.5 a každou novou betu KDE4 zkouším také). To jsem opravdu jediná osoba s poruchou pracovního prostředí na světě?

[error414]

kde3.5 je paradni prostredi, ale po prechodu na kde4 jsem rychle presel na gnome. Nelibi se me kam kde4 smeruje. Gnome je takovy maly windows.

[emorjino]

Mám too podobně. Taky jsem přešel na Gnome (částečně, jenom na netbooku)... Ale přitom se mi líbí, kam KDE 4 směřuje... a vážně se těším na KDE 4.4 nebo KDE 4.5

[Marián Kyral]

Já se taky těším na KDE 4.4, ale to neznamená, že nemůžu čekat na KDE 4.2.

[m1c4a1]

Holt potřeby uživatele se mění. Je to čistě jen o zvyku a Qt aplikace jsou pro většinu lidí přívětivější. Podobné to bylo, když GTK začalo vytlačovat aplikace postavené na Motifu, Atheně a podobných dnes jich historických toolkitech. Já v tom nevidím zas takový problém.

V čem problém vidím a co by mi vadilo, je ztráta možnosti volby. Pokud bude všude jen Qt a KDE, tak nám Linux zwindowsovatí, co se grafické stránky týče. Nejen co se vzhledu týče, ale i s obrovským rozšířením stejné platformy vzroste i šance rozšíření virů.