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 »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
