raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Nové verze AI modelů. Společnost OpenAI představila GPT‑5.5. Společnost DeepSeek představila DeepSeek V4.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 164 (pdf) a Hello World 29 (pdf).
Bylo oznámeno, že webový prohlížeč Opera GX zaměřený na hráče počítačových her je už také na Flathubu and Snapcraftu.
Akcionáři americké mediální společnosti Warner Bros. Discovery dnes schválili převzetí firmy konkurentem Paramount Skydance za zhruba 110 miliard dolarů (téměř 2,3 bilionu Kč). Firmy se na spojení dohodly v únoru. O část společnosti Warner Bros. Discovery dříve usilovala rovněž streamovací platforma Netflix, se svou nabídkou však neuspěla. Transakci ještě budou schvalovat regulační orgány, a to nejen ve Spojených státech, ale také
… více »Canonical vydal (email, blog, YouTube) Ubuntu 26.04 LTS Resolute Raccoon. Přehled novinek v poznámkách k vydání. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 11. vydání s dlouhodobou podporou (LTS).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) byla vydána v nové verzi 1.26.0. Přehled novinek v příspěvku na blogu.
Ve středu 29. dubna 2026 se v pražské kanceláři SUSE v Karlíně uskuteční 7. Mobile Linux Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj i uživatelský prostor. Akce proběhne od 10:00 do večerních hodin. Hackday je určen všem zájemcům o praktickou práci s Linuxem na telefonech. Zaměří se na vývoj aplikací v userspace, například bankovní aplikace, zpracování obrazu z kamery nebo práci s NFC, i na úpravy
… více »LilyPond (Wikipedie) , tj. multiplatformní svobodný software určený pro sazbu notových zápisů, byl vydán ve verzi 2.26.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 11.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 237 vývojářů. Provedeno bylo více než 2 500 commitů. Přehled úprav a nových vlastností v seznamu změn.
10.8.2007 17:55
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
jak bez X? To nejde ne?
Qtopia neni knihovna, ale platforma pouzivajici Qt/Embedded.Díky za opravu, doteď jsem si totiž myslel, že Qtopia je platforma i knihovna, takže jsem zas o něco chytřejší.
Jinak na to 'zahodit X' si staci najit Googlem jeden z tech asi milion pripadu, kdyz uz nekdo dostal tenhle napad driv.Ale já X nechtěl zahodit, já jenom chtěl upozornit na ten fakt, že by nebyl velký problém obě knihovny zprovoznit i bez něj.
10.8.2007 21:01
Josef Kufner | skóre: 70
10.8.2007 19:45
Jardík | skóre: 40
| blog: jarda_bloguje
11.8.2007 10:11
brk | skóre: 29
| blog: broukoviny
11.8.2007 14:42
Petr Tomášek | skóre: 39
| blog: Vejšplechty
To tady opravdu všichni souhlasí s tím, že vykreslování widgetů bez podpory X je výhoda?Podle toho komentáře se zdá, že s tím souhlasím? Mmm...
Staci si nastavit lehci tema (mene prechodu a obrazku) a RLE komprese zaruci velmi dobry vysledek.To je přesně to, čemu je potřeba se vyhnout. Dneska je uživatel zvyklý na to, že GUI aplikace pěkně vypadají a jsou interaktivní. Omezenost AJAXových aplikací zatím uživatelé tolerují, protože přístup odkudkoli tuto nevýhodu (zatím) vyváží, navíc AJAXové aplikace (nebo obecně tencí klienti) se používají na aplikace s jednoduchým GUI. Takže zatím to uživatelé tolerují. Ale „nastavte si jednoduché hranaté ošklivé téma“ rozhodně není marketingový hit, kterým přesvědčíte uživatele.
PS 2: A jake ty vyhody mi X server nabizi?
Doufam ze si nepletete X server a webovy prohlizecNepletu. Jenom si jaksi nemůžu nevšimnout, že se webový prohlížeč dnes často používá k tomu, k čemu byl zamýšlen X server. A používá se k tomu mimo jiné právě proto, že umí nakreslit třeba tlačítko a postarat se o něj komplet – na kliknutí zareagovat jeho překreslením ve zmáčknutém stavu, na získání focusu reagovat vykreslením rámečku atd. Webový prohlížeč ale není ten správný nástroj, který by tohle měl dělat – tohle je úloha právě pro X server (nebo nějakého jeho nástupce). Mimochodem, když jste takový zastánce obrázků – proč se někdo vůbec patlá s nějakými webovými stránkami a webovými aplikacemi v HTML? Vždyť by stačilo na serveru vše vyrenderovat jako obrázek a poslat to do prohlížeče, ne? Odpadly by problémy s různými nekompatibilitami prohlížečů. Aby bylo jasné, kam tím mířím, a abych zase nebyl podezírán ze záměny X serveru a webového prohlížeče – jaký je pro uživatele rozdíl mezi Thunderbirdem a Gmailem? Nechtěl by nakonec uživatel aplikaci, kterou bude mít dostupnou odevšad s nějakým minimálním vybavením (jako je Gmail), ale zároveň interaktivní a s propracovaným GUI, jako je (ehm, skoro) Thunderbird?
Antialiasing si aplikace stejne pocita sama, aspon u pisma.No právě, to je špatně. Co s tím pak má chudák X server dělat, když už to dostane zmršené od aplikace? To pak uživatel klidně může po X serveru chtít zvětšit (lupou) okno, ale když tam X server má jenom černé fleky s duhovými okraji, zpátky z toho nevyčaruje písmo, které by teď mohl vykreslit s daleko prokreslenějšími detaily.
Jenze X Server neni zadny vektorovy graficky server. Stara se o pixely tak mu aplikace musi ty pixely poslat, nebo poslat co se ma kde rasterizovat. Podle me by X server vubec nemelo zajimat, co se v dane aplikaci nachazi, to je ciste vec aplikace a tento obsah se muze menit.X Server je právě „podobojí“, část je vektorová (např. právě okna) a část bitmapová. Budoucnost je podle mne ve vektorovém GUI, a cesta „část vektorová, část bitmapová“ k vektorům přes plně bitmapový desktop mi připadá trochu zvláštní
11.8.2007 22:51
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Dá se to očekávat od Applu, Windows s tím budou muset přijít taky, tak by nemusel být Linux ten třetí vzadu, ne? První krok se povedl celkem dobře, ale aby to tím neskončilo…Naštěstí linux != KDE/Qt... (Vývoj gtk založeného na CAIRu mi v tomto příjde docela slibný...)
Naštěstí linux != KDE/Qt... (Vývoj gtk založeného na CAIRu mi v tomto příjde docela slibný...)To jsem rád, tenhle vývoj jsem nezaznamenal. Tak alespoň něco nadějného…
zjistit, pod krerym detskym oknem se momentalne nachazi kurzor mysi je pro toolkit naprosta malickostto je právě to, co si nemyslím, při větším počtu widgetů už se vyplatí použít nějaký rafinovaný algoritmus, zanedlouho bude také možné použít pro některé výpočty přímo grafickou kartu (ono už to možné je - viz. např. nejnovější počiny NVIDIE), k níž má přístup X server, takže by pak CPU nebylo vůbec zatěžováno, těchto výhod bychom bez X serveru jen těžko mohli v budoucnu využít
a co treba list view, tree view nebo dalsi komplexni widgety?Tam už musí počítat knihovna, to je pravda.
Pri vetsim poctu widgetu bude pro aplikaci vyhodnejsi, kdyz si je bude spravovat sama, protoze si ten algoritmus muze implementovat a optimalizovat pro sve potreby, neni tak?Není
Protože pak každá knihovna bude mít svůj algoritmus, který musí počítat naslepo (aniž by cokoli tušil o zobrazovacím zařízení nebo ostatních oknech). Zatímco X server má právě přehled o celém desktopu, takže dokáže daleko lépe určit, co je nutné kreslit a co ne. Navíc způsobu, jak dělat knihovny widgetů, není zas tolik, aby ty knihovní algoritmy byly nějak moc rozdílné. Takže ten optimalizovaný algoritmus by byl ve všech knihovnách plus mínus stejný – no a to může být rovnou v X serveru.
Není
- Predstavte si, ze by WWW prohlizec posilal kazdy TAG X serveru.
- Aplikace si prece muze zjistit informace o zobrazovacim zarizeni a pozadovanem vystupu (treba pismo pomoci FontConfig(u), bitova hloubka, rozliseni, DPI, ...)
Zatímco X server má právě přehled o celém desktopu, takže dokáže daleko lépe určit, co je nutné kreslit a co ne. Navíc způsobu, jak dělat knihovny widgetů, není zas tolik, aby ty knihovní algoritmy byly nějak moc rozdílné. Takže ten optimalizovaný algoritmus by byl ve všech knihovnách plus mínus stejný – no a to může být rovnou v X serveru.V dobe double-bufferu nema smysl urcovat, co je treba prekreslit a co ne, proste se pouzije double-buffer a aplikace o prekresleni ani nemusi vedet (viz nektere jine prispevky)...
Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )Pokud vim, tak nektere udalosti posila widgetum primo X server a toolkit je jen preklada na neco srozumitelnejsiho, pripade na zaklade nich generuje dalsi udalosti. Tento koncept je pekne videt na knihovne GTK, kde je kazdy objekt window X serveru obalen GdkWindow a u kazde widgety z GTK na pozadi stoji prave jiz zmineny GdkWindow. Je tam take patrne rozliseni udalosti, ktere jdou z X serveru - napr. expose-event a signálů, které už z X serveru nejdou, ale jsou syntetizovány na základě událostí X serveru - např. clicked.
No jo, ale ja myslim propagaci udalosti, ktera prisla z X serveru. Prijde mi treba udalost "Zmacknuta klavesa X" a dane okno ji nezpracuje (nechce ji), tak toolkit tuto udalost propaguje urcitym smerem dal do jinych oken (vetsinou asi rodic).Ano, vetsinou jde udalost smerem k rodici, jenze ja reagoval na nasledujici tvrzeni:
Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )Toolkit totiz pri "zmacknuti klavesy X" nepotrebuje vedet, nad kterou widgetou je mys, protoze mu staci vedet, ktera widgeta ma focus.
Toolkit totiz pri "zmacknuti klavesy X" nepotrebuje vedet, nad kterou widgetou je mys, protoze mu staci vedet, ktera widgeta ma focus.Mel jsem spis napsat, co kdyz zmacknu tlacitko mysi (treba rolovaci tlacitko), tady uz je to snad vice logicke:)
Mel jsem spis napsat, co kdyz zmacknu tlacitko mysi (treba rolovaci tlacitko), tady uz je to snad vice logicke:)Jenze, kdyz zmacknete tlacitko mysi nebo hybnete mysi, tak tu udalost te widgete nad kterou je ukazatel mysi posila opet X server. Jmenovite: button-press-event, button-release-event, pripadne motion-notify-event.
Ve Windows, kde pomalu každá druhá aplikace vypadá naprosto jinak a používá své vlastní skiny a thémata (místo systémových), opravdu musí straaašně záležet na sebemenším detailu
Linux (či FreeBSD) je oproti Windows v tomhle směru na tom přímo výborně.
Nechci aby to vypadalo, ze se zastavam Qt, ale mnohokrat jsem se dival do jejich zdrojaku a odvedli proste vybornou praci.
Ale samozřejmě, že to možné je kreslit prvky. Jen ten výsledek bude polofunkční a nebude zaručen nativní vzhled.Jenže ten výsledek je funkční už dnes, přijde mi, že se se mnou hádáte, aniž by jste Qt pod Windows zkusil (stačí nějaká Qt aplikace)
Jinak P.R. řeči (věřte mi, že je taky umím) ve stylu "firma X.Y. věnovala velké úsilí" jsou moc hezké, stejně tak jako "mají dávno hotové" a "odvedli výbornou práci". Nejsem s prominutím pitomec a Win API znám jako vlastní boty. Pokud Trolltech používá nativní "Windows podokna" (abych se tak trochu vyjádřil ve Vašem stylu, pak odvedli dobrou práci a bude to fungovat ke spokojenosti. Pokud si místo toho kreslí ve Windows vše do jednoho okna, pak sorry - vždycky to bude dřít. Můžete mi tu napsat tisíc stránek dalších P.R. řečí na Qt a Trolltech, ale budou to jen plané lži. Oblbujte si prosím jiné lidi.AAaaaano, samozrejme mate vzdycky pravdu a neco jako Qt udelate za tyden ze
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz #include [QApplication] // zavorky jsou umyslne upravene
#include [QPushButton]
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton hello("Hello world!");
hello.resize(100, 30);
hello.show();
return app.exec();
}
Ve Windows pokud vim NENI mozne, aby bylo tlacitko top-level okno, ale v Qt to jde. Pokud program zkompilujete a podivate se na nej pres Spy++, tak uvidite jen jedno HWND a to je vse. Netvrdim, ze vim vsechno, ale v teto konkretni veci jsem si na 100% jist.
take se loucim v teto diskuzi:_)
Pokud je pravda, co rikate, tak by Qt nemohlo ve Windows vypadat nativne. Jsem si 100% jist, ze bude vypadat nativne i kdyz bude systemove jen jendo top-level okno.Nebude. Javovský Swing řeší to samé – už existují témata, která emulují vzhled Windows nebo GTK. Jenže pořád, když se upraví téma nativních Windows nebo GTK, musí se upravit i to emulované téma. A hlavně – to že aplikace zapadne do nějaké platformy neznamená jen to, jak bude vypadat, ale i jak se bude chovat – tedy to feel z look-and-feel. Na Linuxu to nebude takový problém, tam je feel dáno použitým toolkitem, takže se liší aplikaci od aplikace, ale na Windows nebo MacOS je feel jednotné v celém systému. A obávám se, že konkrétně ve Windows některé specialitky nepůjde ani emulovat, protože jsou zadrátovány někde v systému a není k nim k dispozici veřejné API.
Tiskni
Sdílej:
