Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »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.
Tiskni
Sdílej:
In your face, Gtk! :-)) no.. ale som zvedavy, co s tym bude robit najblizsie roky Gnome...
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.
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.
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
Co jsi se tedy dozvěděl, že to znamená?
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.
ano, pokial neupravis Qt a budes s nim linkovat svoj sw dynamicky (=Qt bude distribuovane v podobe .dll/.so suborov)
Pokud upravíš Qt, tak musíš distribuovat jen změny, které jsi provedl v Qt, ne?
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.
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
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.
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.
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.
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.
Konecne nekdo NORMALNI.To to neslo takhle napsat rovnou ? :o)
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í.... )))
Kdyby tak Trolltech tento správný krok udělal dřív... :)
...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.
to dufam aj ja - ze ubuntu zacne viac riesit KDE napr.
14.1.2009 17:32
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Pak ale nechapes, proc Ubuntu preferuje GNOME. S licenci to nema moc poslecneho, jde o filosofii desktopoveho prostredi, kterou GNOME razi.to dufam aj ja - ze ubuntu zacne viac riesit KDE napr.
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 :)
14.1.2009 20:44
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
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.
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)
naproti tomu ked som videl KDE, tusim v2, prvykrat, vedel som celkom intuitivne, kde co jeto ale mohlo být kvůli podobnosti s windows.
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í.
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é...
To by KDE ale muselo trochu zmenit pristup ... :/
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ď?
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) ...
Co do verze 3.5 - chybi podpora do budoucnosti, bez vyvojeStabilní, ozkoušené a odladěné prostředí, udržovat se ještě nějakou dobu bude - pro firmy docela ideální.
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.
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 ;)
Aplikace se musely ..už to vidím a opravit to po odeslání nelze, grrr
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
Problém je, že pro knihovnu Qt existuje strašně málo bindingů do jiných jazyků.
Například OCaml, Erlang, Haskell...
) Ale s těmito jazyky začínat výtku na adresu Qt slovy problém je, to je dost odvážné
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.
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
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í.
14.1.2009 11:53
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
V akademickem prostredi ano.
14.1.2009 13:11
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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.
Ale pokud vím, je to spíš výjimka.
Mozna se jen nepohybujes v tech spravnych kruzich ...
(Kam nedohlednu, to neexistuje?)
14.1.2009 15:36
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Až na to, že mainstreamové jazyky čerpají nápady z těchto okrajových jazyků.
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.
Srovnavat Haskell s Whitespace ... (aneb nemamli argumenty, jednoduse zabehnu do extremu ...)
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 ...
hmm, c++, c#, python, perl, java, javascript, ruby.. co konkretne ti este chyba?
a pozeram ze su aj pre haskell, php
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.
mozete mi prosim postkytnut nejaky link na bindings pre C# ? pretoze ja som povacsinou narazil na mrtve projekty...
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...
)))
tohleto dávno vim. )
))
14.1.2009 17:42
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
alebo ku krita-e...
V čem je problém? Nativní port Gtk+ pro Mac OS X existuje (ačkoli je mnohem mladší, než port Qt pro OS X).
14.1.2009 23:38
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
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.
Ří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ší.
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. ))
IMHO je ideologicky boj C vs C++ mnohem hlubsi nez byl LGPL vs GPL.
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...
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.
Neznamená to, že by se pro eclipse mohlo použít na gui qt?
14.1.2009 12:58
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
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.
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
14.1.2009 09:21
15.1.2009 17:47
14.1.2009 23:17
14.1.2009 18:36
14.1.2009 13:20
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.
nuz, toto sa dalo cakat ! super! dufam, ze to nie je 1. april
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....
14.1.2009 12:56
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
14.1.2009 15:18
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
.
).
i když první vlaštovky přechodu na Qt tu již byly - třeba VLC nebo AvidemuxAvidemux nikdy na Qt nepřešel (ani o to nikdy neusiloval). Jenom to přidal jako další možnost.
14.1.2009 13:15
David Watzke | skóre: 74
| blog: Blog...
| Praha
Výborná zpráva. Konečně bude Qt v mých očích konkurenceschopná. Opravdová konkurence pro Gtk.
To musí mít radost lidi, co si před týdnem koupili licence... Nic ve zlém.
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.
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.
14.1.2009 18:02
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
moc). No, objev generování kódu takové lidi nejspíš ještě čeká
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.
, 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.
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.
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.
moc AFAIK musí rozumět syntaxi C++, což cpp (skoro) nemusí. Asi jste mě překecali
#define "konstantní" proměnnouNebo můžu použít úplně jiný makroprocesor nebo šablonový systém. Jako správný zvrhlík si dokážu představit namístoTo 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žtocpppoužívat třeba Velocity
moc generuje C++ kód, který je prostě jenom pohodlnější generovat automaticky.
Jinak mezi kompilátory různých IDL aPředstav si, že autoři zvolili pro IDL trochu ošperkovaný C++ jako výchozí jazyk a paralela je snad evidentní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, zatomoc(icpp) bere trochu ošperkovaný C++ kód a generuje zase C++ kód.
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á:Nemyslím, že je #define sémanticky shodné s konstatní proměnnou#define"konstantní" proměnnou
#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.
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ý
Wow super zpráva. Ikdyž jsem to trochu čekal (no spíš doufal jsem v to), když Nokia otevírá i Symbian.
15.1.2009 13:03
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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ě?
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.
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
18.1.2009 09:23
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Já se taky těším na KDE 4.4, ale to neznamená, že nemůžu čekat na KDE 4.2.
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ů.
16.1.2009 01:00
16.1.2009 01:55