Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána verze 9.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 83, V8 na verzi 8.3 a Node.js na verzi 12.14. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Tiskni
Sdílej:
Diskuse byla administrátory uzamčena
Apku nemusis psat v JS. Klidne v C nebo Rust, compile target WASM a to spustis v Electronu nativne.Pokud vim, tak to teoreticky jde, ale stále to není ono. IIRC je potřeba JS glue code a je to celé takové v plenkách...
Vyznam Electronu je, ze jako vyvojar nemusis resit cely ten bordel od kernelu, pres drivery az po X11, to uz za tebe udelali chudaci v Chromiu.Což o to, bordel od kernelu až po X11 řeší i tradiční toolkity. Co IMO má Electron (resp. obecně browser enginy renderující HTML) navíc je etrémně flexibilní a na featury bohatý layout engine. Běžné toolkity nabízí nějakou sadu widgetů a možností layoutu a když chceš cokoli mimo to (a nestačí ti jen skládat a ohýbat existující widgety), tak musíš jít pěkně low-level na nějakej canvas a kreslit (a layoutovat!) si to sám pixlík po pixlíku jak ve středověku... Výjimkou je (asi) QML, ale přiznám, že layoutovací schopnosti QML do detailu neznám...
Běžné toolkity nabízí nějakou sadu widgetů a možností layoutu a když chceš cokoli mimo to (a nestačí ti jen skládat a ohýbat existující widgety), tak musíš jít pěkně low-level na nějakej canvas a kreslit (a layoutovat!) si to sám pixlík po pixlíku jak ve středověku...Proč lžeš? GUI komponenty se v toolkitech jako Qt, GTK, Java/Swing atd. běžně skládají dohromady. Ze základních prvků (tlačítka, formuláře, labely, panely, scrollpanely atd.) skládáš větší a větší celky, nastavuješ jim okraje, dáváš do layoutů případně si píšeš layouty vlastní. Kreslit nějaké pixely do canvasu v drtivé většině případů nepotřebuješ. Pracuješ na úrovni komponent/objektů.
Tak nevím, jak by mi zrovna Electorn měl v tomhle pomoci?Pravděpodobně by nebylo těžké napsat transformaci z dat commit grafu do nějakého SVG, ke které by pak jako bonus šlo stylovat přes CSS (takže např. přepínání light vs dark mode by asi nebyl problém) a do kterého by nebyl problém dodat nějakou interaktivitu. Viz též d3js (což ale není jediný a ani neříkám že nejlepší způsob).
A jinak se určitě nekreslí pixlíky, Ani v tom vašem odkazovaném zdrojáku se nekreslí pixlíky.Jasný, ale musíš tam počítat s fyzickými pixely. Mně na tom nejvíc vadí, že to je imperativní kód. Udělat v tom nějakou změnu bude hrozná práce, muselo by se to celý projít a upravit ty výpočty, řešit co se kde rozbije atd. Podobný kód jsem několikrát musel psát nebo upravovat. Je to kód, který je zdlouhavý napsat a když je hotový, tak se v něm o 2 týdny později už nikdo nevyzná a nedá se snadno měnit. Oproti tomu pěkná vlastnost třeba toho HTML a SVG nebo dalších webových technologií je, že jsou deklarativní. Uznávám, že mají taky svoje problémy, např. SVG saje co se týče layoutingu textu (ale v prohlížeči se to afaik dá řešit).
A třeba např. v JavaFX máte k dispozici libovolné grafické prvky, které můžete rozšiřovat, animovat, dynamicky napojovat a o kreslení pixlíků se stará engine.JavaFX moc neznám. By byl někde příklad kódu, kde je implementovaná nějaká custom komponenta? Z těch stránek mi přijde těžký se na něco takovýho proklikat (nebo jsem možná jen unavenej). No nicméně ve chvíli, kdy se vytahne Java, tak je otázka, jestli má cenu nějak brojit proti Electronu, vzhledem k tomu, že UI v Javě typicky mají podobný nevýhody co se týče pomalosti a žravosti paměti...
Dělal jsem třeba v Sencha ExtJS což je hodně podobné desktopovému vývoji, ale v případě první chyby se to nesmírně komplikuje - hledat chybu v stacktrace minifikovaném js knihovny třetí strany je peklo, podpora pro refaktoring špatná a chybějící typovost mi obecně nesedí. Tíhnu k silné typovosti a pozdní vazbě, které tomu dodá dynamičnost.Jo, s tim souhlasim. Kdybych měl teď dělat něco v Electronu, určitě bych chtěl minimálně TypeScript...
Java samozřejmě není zdaleka ideální, bohužel i ostatní jvm jazyky jsou omezené třeba type erasure, což dost limituje generika atd.Heh, zrovna o tom byla debata o kus vedle...
Vyhodou oproti electronu je, ze vykreslovaci jadro je navrzeno na grafiku a GUI, ne na zobrazovani stranek, ktere se tvari jako GUI, to umoznuje mit kod znacne jednodussi, rychlejsi a uspornejsi.No, prohlížeče používaj afaik na vykreslování knihovnu Skia, což je prostě grafická knihovna. Ale to je vespod, samozřejmě nad tim je věc, která počítá s html "dokumenty", což ano, má svoje problémy.
Co do vykonu je u me Java+JavaFX vyrazne rychlejsi a uspornejsi na pamet.Hm, já jsem nikdy neměl příležitost nějakou JavaFX aplikaci používat a ani z hlavy o žádný nevim. Co se týče Java GUI aplikací na desktopu, zkušenost mam předevšim s IDE případně nekolika menšími aplikacemi a vždycky mi to GUI přišlo šílené pomalé, hnusné a bloated. Ale je pravda, že nic z toho nebylo JavaFX. Co se týče Electronu, čekal bych, že s tim zahejbe WASM, až bude konečně někdy mít podporu pro managed jazyky a bude víc first-class citizen. No jinak ale existují i další příbuzný technologie, zmiňoval jsem třeba QML nebo existuje taky Flutter (který ale bohužel zabíjí nutnost používat Dart).
No, prohlížeče používaj afaik na vykreslování knihovnu Skia, což je prostě grafická knihovna. Ale to je vespod, samozřejmě nad tim je věc, která počítá s html "dokumenty", což ano, má svoje problémy.Coz je presne to, na co narazim. V JavaFX, Qt a podobne mas pro tvorbu layoutu nachystane komponenty, coz jsou ve skutecnosti velice male a primitivni objekty. Vedle toho v Electronu na to slouzi brutalni engine, ktery musi pocitat s tim, ze bude delat layout pro vsechny typy objektu (text, obrazky, tabulky) a se vsemi zbesilymi vlasnostmi pozicovani.
Co se týče Java GUI aplikací na desktopu, zkušenost mam předevšim s IDE případně nekolika menšími aplikacemi a vždycky mi to GUI přišlo šílené pomalé, hnusné a bloated.To je dane tim, ze u starsich programu je jako toolkit pouzita knihovna Swing, ktera je komplet v Jave, tj. JIT prekladac typicky nedostane dost casu, aby kod zkompiloval a neni k dispozici akcelerace. JavaFX je v jave pouze castecne a jde to poznat.
Co se týče Electronu, čekal bych, že s tim zahejbe WASM, až bude konečně někdy mít podporu pro managed jazyky a bude víc first-class citizen.Ze je Electron postaveny na JS, je podle me jen cast problemu, ta mensi. Z meho pohledu je nejvetsi zverstvo to, ze na vykreslovani se pouziva kompletni prohlizec a mas tam dva JS runtimy, ktere si spolu vykladaji (nekdy i po HTTP).
Coz je presne to, na co narazim. V JavaFX, Qt a podobne mas pro tvorbu layoutu nachystane komponenty, coz jsou ve skutecnosti velice male a primitivni objekty. Vedle toho v Electronu na to slouzi brutalni engine, ktery musi pocitat s tim, ze bude delat layout pro vsechny typy objektu (text, obrazky, tabulky) a se vsemi zbesilymi vlasnostmi pozicovani.Ten přístup á la Qt mi přijde dost příšerný. Ty toolkity v podstatě obsahují sadu několika malých "layout enginů", který se daj trochu naparametrizovat, ale víceméně jsou spíš fixní, a musíš vybírat, který je v které chvíli vhodný. Typicky to skončí tim, že je musim nějak obehjbat a hledat, jakou kombinací se docílí toho, co chci, případně přidávat custom kód, který tomu pomůže. Samozřejmě i v HTML/CSS musí člověk hledat a ohejbat, ale má to mnohem lepší granularitu IMO a v dnešní době s flex layoutem etc. už to není zdaleka takový utrpení jako ~2009. Navíc layout v 'tradičních tookitech' se blbě debuguje / blbě se zjišťuje, co který layout kde udělal. Oproti tomu browser dev console ti zobrazí přesně co se děje, hranice objektů nebo celých stromů, vlastnosti, vypočtené i nastavné, můžeš si s tim naživo šibovat, měnit vlastnosti... Ten přístup v browseru mi přijde mnohem lepší - jeden layout engine, který je možný velmi flexibilně parametrizovat, takže můžeš udělat co chceš a kde chceš. Nemyslim si, že by zrovna v tomhle bylo nebo mělo být výkonově úzký hrdlo. IMO ten výkonový problém je v tom, že browsery nenabízejí dobré API pro práci s DOMem, konkrétně to API nemá žádný batching / transakční zpracování. Což je průser jak kráva. Tradiční toolkity od začátku obsahují API, kde mu řekneš "teď nepřekresluj, aktualizuju obsah" a "dobrý, můžeš zase překreslovat", bez toho by to taky bylo hrozně pomalý. Tvůrci JS toolkitů a uživatelé musí tohle řešit v JS, odtud různé virtual DOM [1, 2], fastdom a podobně. A samozřejmě řešení v JS nad DOM API sice pomáhá, ale nějak dramaticky výkonné nikdy nebude. Dát tohle přímo do DOM API by IMO zvedlo výkon dramaticky.
Ze je Electron postaveny na JS, je podle me jen cast problemu, ta mensi. Z meho pohledu je nejvetsi zverstvo to, ze na vykreslovani se pouziva kompletni prohlizec a mas tam dva JS runtimy, ktere si spolu vykladaji (nekdy i po HTTP).Jo, ta kombinace node.js a browseru je hrozná, s tim souhlasim a to je to, čemu říkám prasopes...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
