Americký výrobce čipů Intel propustí 15 procent zaměstnanců (en), do konce roku by jich v podniku mělo pracovat zhruba 75.000. Firma se potýká s výrobními problémy a opouští také miliardový plán na výstavbu továrny v Německu a Polsku.
MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
V posledních pár týdnech jsem svoji pozornost zaměřil na XUL - jazyk založený na XML sloužící k popisu uživatelského rozhraní, který využívájí především projekty založené na Gecku. Rád bych zde shrnul pár svých postřehů.
Pokud svůj projekt vybavíte webovým rozhraním, pravděpodobně nakonec narazíte na hranice dané tím, že uživatelské rozhraní je zobrazováno webovým prohlížečem, který si např. přivlastní některé klávesové zkratky, bývá poměrně pomalý a realizace některých základních prvků, které grafická uživatelská rozhraní mají už od plínek (kontextová menu, oddělovače apod.) se zde realizují jen značně komplikovaně. Konec konců, HTML stránky původně vznikly pro zobrazování hypertextových dokumentů a nikoliv pro tvorbu uživatelských rozhraní. Na druhou stranu nabízí dynamicky generované HTML stránky značnou flexibilitu a platformní či licenční nezávislost, kterou naopak můžete postrádat u různých GUI toolkitů.
XUL svým způsobem umožňuje zkombinovat to nejlepší ze světa webových a nativních rozhraní. Nedaří se mu to úplně dokonale a samozřejmě i on má své limity a úskalí, ale pro celou řadu projektů se jedná o rozumnou volbu.
XUL definuje uživatelské rozhraní, které je pak zobrazováno uživatelům speciálním renderovacím jádrem v s pokud možno takovým vzhledem a ovládáním, na jaké je u své platformy nativně zvyklý. O vlastní aplikační logiku se musí starat někdo jiný. Často se jedná o nativní kód propojený se zobrazováním GUI přes speciální rozhraní (XPCOM). To je vhodné především pro samostatné lokální aplikace. Další dnes velmi oblíbenou možností uplatňovanou především u rozšíření Firefoxu je napsat celou logiku pomocí JavaScriptu
Mě zajímala hlavně třetí možnost - vzdálené generování XUL přenášeného přes HTTP podobně jako u HTML stránek. Tato varianta je výhodná především pro intranetové aplikace, má ale některá nepříjemná omezení (viz dále).
Mým cílem bylo umožnit generování XUL kódu ze smalltalkovského webového frameworku Seaside a vyřešit si tak věčnou otázku nativního smalltalkovského rozhraní se standardním "Look&Feel". Samozřejmě lze podobně postupovat i na jiných platformách. Pokud Vás Smalltalk vyloženě nezajímá, tuto kapitolku můžete přeskočit. Seaside je komponentový kontinuační webový framework, který velice zdařile umožňuje vytvářet webové aplikace přirozeným způsobem tak, že je jejich tvorba velmi podobná tvorbě aplikací s nativním GUI. Přímo se proto vybízí Seaside k tomuto cíli využít přímo.
Seaside nepoužívá primárně žádný šablonovací systém a jde raději cestou skládání jednoduchých univerzálních komponent. HTML kód je generován přímo ze Smalltalku pomocí Canvasu s využítím bloků. Hlavním úkolem tedy bylo vytvořit speciální canvas, který místo HTML kódu bude produkovat XUL. Tvorb uživatelského rozhraní pak vypadá např. nějak takto:
xul groupBox flex: 1; with: [ xul caption label: 'orientation'. xul vBox with: [ xul description value: 'some text'. xul checkbox label: 'Left'. xul separator flex: 1. xml button flex: 1; label: 'Submit'. ]].
Seaside je navržena pro HTML, kdy se při zaslání požadavku klientem generuje celá stránka a značnou část svého know how věnuje tomu, aby tím programátor byl obtěžován co nejméně. Pro XUL je tento přístup ale krajně nevhodný a překreslovat celé uživatelské rozhraní vždy, když uživatel udělá nějakou výraznější změnu, je nesmyl. Proto musela přijít ke slovu komunikace prostřednictvím XMLHttpRequestů. Ty se sice v Seaside také používají, nicméně ne pro operace jako volání komponent, kde by už implementace byla dost problematická.
Víceméně jsem musel nad Seaside postavit vrstvu, která veškerou komunikaci zprostředkovává přes Ajax. Bylo tedy nutné ve XUL kódu vymezit komponenty (nechápu, proč v definici XULu není žádný element pro vymezení logické oblasti dokumentu bez vlivu na zobrazní), aby s nimi šlo samostatně pracovat, a dále se postarat o zpracování volání kompoennt přes XMLHttpRequesty. O co konkrétně jde, si ukážeme na příkladě:
xul button label: 'login'; onCommand: (xul ajax callback: [ | user | user := self call: LoginComponent new. self call: (UserInfoComponent new user: user) ]).
V tomto příkladě jsme na komponentu umístili tlačítko, na které když uživatel klikne, objeví se místo původní komponenty komponenta se zadáním přihlašovacích údajů. Po jejich vyplnění se místo přihlašovací komponenty objeví jiná, která zobrazí informace o uživateli.
Samotné dočasné nahrazení jedné komponenty jinou se řeší jednoduše pomocí dekorátoru, který deleguje prováděné operace a zobrazování na nahrazující komponentu. Složitější je to s řízením toku, protože při zaválání komponenty se musí aktuální výpočet přerušit (počkat na výsledek volání), zaslat klientovi příkaz zobrazení volané komponenty a v okamžiku, kdy volaná komponenta na uživatelův popud vrátí řízení zpět, pustit výpočet dále, ovšem s tím, že nyní již reagujeme na jiný požadavek klienta (generujeme odpověď na jiný XMLHttpRequest). Naštěstí i toto šlo nakonec s pomocí výjimek a kontinuací vyřešit doslova na pár řádcích. Pro to, aby bylo možné pracovat jednoduše s více vstupními elementy zároveň, bylo nutné zavést i jistou alternativu k HTML formulářům.
Nejjednodušší možnost, jak zobrazovat vzdáleně generovaný XUL, je použít přímo Firefox. Ten si ovšem podobně jako v případě HTML stránek zabírá některé klávesové zkratky apod. Nicméně se jedná o nejvhodnější možnost v průběhu vývoje, protože je možné použít např. rozšíření Firebug.
Druhá možnost je použít samostantý XULRunner, kdy pro aplikaci nejdříve vytvoříme sadu pár konfiguračních souborů, viz (http://developer.mozilla.org/en/docs/Getting_started_with_XULRunner). XULRunner zatím není ve finální verzi. Malá perlička z natáčení - když jsem chtěl otestovat nejnovější night-build XULRunneru pro Windows, při startu hlásil velice nekonkrétní a podivnou chybu. Když jsem ji předhodil googlu, vypadlo mi z něj, že se jedná o chybu, kterou hlásí programy vytvořené v nových Express verzích VisualStudia, když běží na strojích, kde VisualStudio není nainstalované.
Třetí možností je nový Firefox 3 zavolat s parametrem -app, kdy mu předáme odkaz na ini soubor aplikace. Jak pro XULRunner tak pro Firefox 3 stačí uvést URL do souboru prefs.js, např.:
pref("toolkit.defaultChromeURI", "http://localhost:8888/seaside/SeasideXUL%20Periodic%20Table/");
Takto pouštěný XUL má ovšem silná bezpečnostní omezení. Hodně limitující je např. nefunkční XUL element editor, což je krajně nepříjemné zejména z toho důvodu, že víceřádkový textbox je téměř nepoužitelný.
Mozilla nabízí tři možnosti, jak si kýžená vyšší bezpečnostní oprávnění zajistit, což je celkem dost, bohužel prakticky použitelné není ani jedno.
První možností je používat podepsané skripty a jiné zdrojové soubory, které jsou umístěny do jar archivu. Tato varianta je prakticky nepoužitelná, protože je vyžadován certifikát od uznávané certifikační autority, které vám ho jen pro dobrý pocit nevydají. Navíc takto samozřejmě nelze podepisovat dynamicky generovaný obsah. Dále se uvažuje, že tato možnost bude v budoucnu zcela zrušena.
Druhou možností je vytvořit konfigurační soubory aplikace a zdrojové soubory zaregistrovat do chrome. To by byla pro distribuci schůdná varianta, kdyby do chrome nešly registrovat jen lokální soubory (file:///).
Třetí doporučovaná a jediná plně podporovaná varianta je vytvořit si vlastní rozšíření, které bude se vzdáleným serverem přímo spolupracovat. K tomu bych dodal ještě pár slov, z nichž by ale ani jedno nebylo použitelné ve slušné společnosti, tak raději budu mlčet.
Nakonec jsem přišel ještě na jednu cestu, jak dosáhnut požadovaného cíle, ovšem nedokážu se ubránit dojmu, že se jedná o nevzhledný hack, který v příštích verzích už nemusí fungovat. Nezbývá než doufat, že pokud se tak stane, dají nám vývojáři z Mozilly nějakou rozumně použitelnou alternativu.
Do souboru chrome.mainfest se zapíše odkaz na lokální soubory a vytvoří se overlay odkazující na server, např.
content myapp file:content/ overlay chrome://myapp/content/main.xul http://localhost:8888/seaside/SeasideXUL
Dále se do v lokálních souborech vytvoří XUL soubor main.xul, který vytvoří hlavní okno bez obsahu - nadefinuje pouze titulek a velikost okna. Nakonec se tento soubor definuje jako vstupní pro aplikaci v souboru prefs.js
pref("toolkit.defaultChromeURI", "chrome://myapp/content/main.xul");
XUL je velice zajímavá a slibná technologie, ale ještě nevyrostla z dětských nemocí. Jistě by doznala většího rozšíření, kdyby vývojářům neházela zbytečně klacky pod nohy.
Tiskni
Sdílej: