Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
V čem se obě knihovny liší, je způsob jakým pracují s GUI prvky. Qt má veškeré vykreslování vlastní a na jednotlivých platformách se mění pouze vzhled. To umožňuje snadnější portování na další platformy, umožňuje to nabízet větší množství prvků, než jaké poskytuje grafická knihovna cílového prostředí. Nevýhodou tohoto přístupu je pak nižší rychlost vykreslování, než u nativní knihovny.To s tou rychlostí je nepřesné. Žádná nativní GUI knihovna pro Linux neexistuje. V konkrétním případě bude pomalejší spíš wxWidgets, protože používá další multiplatformní toolkit - Gtk+. Kód tedy prochází přes více vrstev, než se dostane k X11.
wxWidgets naproti tomu využívá GUI prvky cílové platformy, což má přesně opačný efekt. V praxi to pak například znamená, že při spuštění programu v GNOME wxWidgetsvyužívá knihovnu GTK k vykreslování. Rozdíl ve výkonu by se měřil poměrně obtížně, žádný obrovský rozdíl ve výkonu oproti Qt tam ale pravděpodobně nebude.Opět
LicenceV praxi je rozdíl mezi LGPL a wxWidgets licencí ten, že v případě wxWidgets můžes zkompilovat celou knihovnu staticky k tvoji aplikaci. V Qt tento postup není možný bez komerční licence.
Rozdíly jsou i při sestavování programu. Při použití Qt zdrojový kód nejprve projde skrz MOC(Meta Object Compiler), který zdroják před zkompilováním modifikuje.MOC nikdy nemodifikuje zdrojový soubor, ale vytvoří úplně jiný, s příponou
.moc
.
Něco k zamyšlení – kolekceNebo můžeš napsat třeba
std::vector<Cat>> seznam
To s tou rychlostí je nepřesné. Žádná nativní GUI knihovna pro Linux neexistuje. V konkrétním případě bude pomalejší spíš wxWidgets, protože používá další multiplatformní toolkit - Gtk+. Kód tedy prochází přes více vrstev, než se dostane k X11.A jak by to bylo s rychlostí na windows, tam bude wx rychlejší? Zajímalo by mě, jak by bylo možné to otestovat, nějaký nápad?
MOC nikdy nemodifikuje zdrojový soubor, ale vytvoří úplně jiný, s příponou .moc.Tak jsem to myslel, trochu špatně jsem se vyjádřil. To že se v tom obtížně navrhuje layout mi vadí asi nejmíň. Horší jsou nekonzistence v pojmenovávání metod tříd, nebo třeba fakt, že některé metody nefungují intuitivně tak jak by měly: např. třída wxCommandEvent má naprosto nelogicky metodu IsChecked(), která funguje jen tehdy, pokud byl event vyvolaný z checkboxů nebo menu (přitom může být vyvolaný ze spousty jiných prvků a korektní postup je získat z eventu zdrojový prvek a z něj teprve zjistit stav). To vypadá jak kdyby to tam někdo přidělal právě když to potřeboval. Srovnání API můžu udělat pokud je o to zájem, nechtěl jsem to přespříliš natahovat, dlouhé zápisky nikdo nečte.
To s tou rychlostí je nepřesné. Žádná nativní GUI knihovna pro Linux neexistuje. V konkrétním případě bude pomalejší spíš wxWidgets, protože používá další multiplatformní toolkit - Gtk+. Kód tedy prochází přes více vrstev, než se dostane k X11.Neexistence nativního GUI je spíš důsledek architektury a minulosti vývoje X Windows než Linuxu. Sice by se dalo říct, že kombinace Xt+Xaw/Motif (resp. jeho otevřené implementace) by se za určitých okolností mohly považovat za nativní GUI, ale pokud dáme jako podmínku, že ostatní toolkity fungují srz něj, tak už to neplatí (ty komunikují přes nižší vrstvu Xlib/XCB). Mimo toho, XServer funguje na mnohem nižší úrovni než widgety, samotný protokol je spíš na úrovni jednoduchých grafických knihoven typu SDL: klient si udělá okno, do něj může kreslit jak vektorově (včetně psaní pomocí fontů), tak bitmapově (přes pixmapy) a XServer mu zas zpět posílá události.
Popravdě, spíš jsem čekal nějaké srovnání API.V tomhle je docela zajímavé porovnat řešení vláken. v Qt totiž imho kvalita API QThread (případně příbuzných) pokulhává za zbytkem Qt, a to především proto, že to je jedno API pro dva různý use cases - a sice "klasická" vlákna a vlákna s event loop, čili, řekl bych, "gui-aware" vlákna. Uživatel na to musí dost pamatovat, aby tyhle dva přístupy v jednom API nemíchal, musí mít stále na paměti, jestli má nebo nemá nastartován event loop a který postupy jsou vhodný pro event loop a který ne. Imho by možná nebylo marný to rozdělit na dvě třídy. Krom toho co si vzpomínám, v některých detailech byla dokumentace QThread trochu vágní, co jsem to viděl naposled... Na druhou stranu je hezké, že v dokumentaci Qt mají všade (co vím) důsledně specifikováno, co je thread-safe a co ne. Co se týče wxWidgets a vláken - koukám do dokumentace a zjišťuju, že něco jako "gui-aware" vlákna vůbec neřeší, k dispozici jsou jen "klasická" vlákna. API vypadá slušně, ovšem já ale wx neznám z praxe (taky jsem nebyl dál než u hello world). Zajímavý je koncept detachted thread, tohle afaik v Qt vůbec není a mohlo by to imho dost zjednodušit práci v některých případech, především pro začátečníky. Ačkoli trošku z toho kouká podobný problém jako v Qt - jedno API, dva use cases.
zde mam pocit, ze ten signal-slot konzept je jakasi mantra intergalaktickeho programovani
Mym hlavnim kriteriem byla multiplatformost a licence. V dobe pred cca 5 lety, Qt v podstate multiplatformni nebylo a licence byla nepouzitelna. S multiplatformosti uz hodne postoupili, licence je sice o dost lepsi, ale porad to neni rozumne pouzitelna licence. Rozhodne neni jistota, ze ta knihovna se bude dat pouzivat bez obav i za 5 let. To je bohuzel obecne problem softu spravovanem jednou firmou.
V současnosti to jen občas používám jako uživatel. A protože jsem, co se optiky týče, řekněme nadstandardní uživatel, tak jsou wx-Gtk víc než na prd. Jsou nahovno (přetékající písma při exotických velikostech, zároveň nedokreslované widgety). Ale zase to může být chyba v Gtk. Nevím.
Používám několik aplikací ve wxWidgets a je to tórčr.
Tiskni
Sdílej: