Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
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
