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 »Je už delší dobu známo, že současný způsob ovládání počítače má svoje mouchy. Jaká jsou dnes nabízená řešení? Ve způsobu chápání počítače Plan 9 (kde je všechno soubor), Squeak (kde je všechno objekt) a ve způsobech ovládání počítače GUI, ZUI, CLI, a nějaké to 3D rozhraní. Každé se hodí na něco. Ale pro běžnou, precizní, rychlou, intuitivní a cílevědomou práci s počítačem je potřeba změnit jak přístup k chápání počítače tak i přístup k jeho ovládání.
Dobře, řeknete si, ale jak by to mělo vypadat? Tak co třeba takto...:
V systému existují zatím blíže nespecifikované modely, které se skládají z komponent. Velmi pravděpodobné je, že modely budou reprezentovány v XML standardizovaném formátu. Funkční okna jsou potom taková okna, která umožňují nějaký specifický pohled na tyto modely.
Pro představu například model kalendáře je složen z komponent, kterými jsou dny a uvnitř těchto dnů jsou komponenty textu (poznámky). Funkční okno (FW) stojí nad tímto modelem a je jistým náhledem na něj. Může existovat FW, které zobrazí kalendář jako sloupec dnů a poznámek vedle nich, stejně jako může existovat FW zobrazující standardní kalendář s vyznačenými dny.
Je zřejmé, že takto vznikají soubory (množiny) funkčních oken, které se hodí k prohlížení standardizovaných množin modelů. V základní představě je barevné rozlišení typů FW – grafika je ve spektru červené, kancelářské dokumenty mají světlé barvy, videa jsou v odstínech modré a podobně. Zkrátka nad jeden model může uživatel umístit různá okna, ale právě jen taková, která umí model přečíst. K jednomu typu modelu patří jeden typ okna – se stejnou barvou. Okna jediného typu se pak liší pouhým způsobem pohledu na stejný objekt.
Uživateli je dána volnost, jaké okno si pro práci s modelem vybere. FW ovšem není jen nějakou křišťálovou koulí vizualizující model schovaný v systému, je to zároveň i tunel, skrze který se uživatel může modelu dotknout.
Mezi základní funkce FW patří samozřejmě změna „úhlu“ pohledu na model. Uživatel se může přesouvat nad různá místa modelu a do výřezu okna tím umisťovat ty komponenty modelu, které ho právě zajímají. FW by ovšem mělo nabízet i umisťovaní pomocných objektů (helpers - vodící lišty, mřížky, kurzory, atd...) a možnost výběru konkrétní komponenty, nebo množiny komponent.
Tím by ale měli schopnosti FW vůči modelu a uživateli končit. Jakoukoli modifikaci modelů – různé výpočty a transformace, kompozice a umisťování nových komponent, by měl zařídit editor.
Editor je vlastně množinou funkcí, které je možno aplikovat na nějaký model, nebo na komponentu modelu. Uživateli je dána možnost vzít oblíbený editor a přichytit ho k FW. FW předá editoru ukazatel na model, který je právě pod ním a naváže s editorem komunikaci v podobě předávání událostí.
K základní množině funkcí, které připadají funkčnímu oknu (a které mohou být reprezentovány tlačítky), přibudou další, které jsou vlastní vybranému editoru. Editor má jednu pevně danou nabídku funkcí, které souvisí s celým modelem, nebo které souvisí s administrativou editoru. Tyto funkce jsou přístupné v jakékoli fázi práci. Pak editor nabízí ještě další funkce, které souvisí s právě vybranou komponentou (nebo komponentami). Velmi praktické je tyto funkce nabízet v kontextovém menu, protože jsou pak rychle přístupné.
Základními funkcemi editoru je vznik nových komponent modelu, úprava stávajících komponent, mazání komponent a přesuny komponent.
Vzhledem k tomu, že existuje možnost, že komponenta je také modelem, stojí za zvážení aby editor vyvolával jiné editory na vybrané submodely (v podstatě jakási varianta objektového přístupu).
Naznačené vlastnosti FW jsou z velké části inspirované objektovými prostředími jako Smalltalk nebo Mac OS X. Aby práce s FW byla opravdu komfortní, je třeba dotáhnout úvahy o nich až do konce. O modelech se zatím hovořilo čistě akademicky ve smyslu toho, že uvnitř systému jsou reprezentovány XML souborem.
XML je vhodný formát pro množství modelů z hlediska jeho standardizace a „čitelnosti“. Není však vhodný pro ukládání binárních dat, velkých objemů dat, systémových zdrojů (a v neposlední řadě konfiguračních souborů – „možná“ - o konfiguraci bude ještě řeč).
Pokud jde o velikost, lze XML bezztrátově zmenšit kompresí. Jsou ale případy, kdy je nutno k modelu přistupovat jako k proudu (řadě dat neboli streamu) a XML formát by pak práci nepříjemně zpomaloval. Stojí pak za zamyšlení, zda je možné vytvořit jakýsi „warp-XML“, což by byl neexistují XML obal dat, který by se choval trochu jako objekt – nebo něco na ten způsob.
V souvislosti s XML se ještě objevuje problém meta-informací. Čili informací, které s vlastním skutečným stavem modelu nemají mnoho co do činění, ale jsou výhodné pro budoucí editaci (v případě používání většího množství editorů by mohlo docházet ke kolizím).
V pozadí povídání o XML formátu stojí nevyřčená skutečnost, že model by byl uložen na disku a pokud by se nad něj postavilo funkční okno, asi by bylo výhodnější umístit jej do paměti.
Umístění modelu do paměti by mělo být transparentní. Měla by existovat možnost jak do paměti nahlédnout a jak prolistovávat načtené modely. Velmi snadno tímto způsobem uživatel dosáhne například zobrazení jednoho modelu ve více oknech. Níže bude naznačeno, že v podstatě celý systém by měl být transparentní a modely a editory a funkční okna, tedy vše, co by mohlo být uloženo v paměti, by mělo být snadno přístupné a přehledně uspořádané (například do hierarchie, které by byla virtuálně připojena do systému souborů).
Důležitou otázkou je, jak a kdy se bude v paměti uložený systém zálohovat a jak budou vratné všechny provedené akce.
Verzování, tedy ukládání rozdílových verzí editovaných modelů, je jednou z nejdůležitějších funkcí, jaké by měl systém podporovat. Verzování by nemělo být v kompetenci ani editoru a ani zřejmě formátu modelu, ale samotného systému. Mělo by být možné nastavovat množství vratných kroků pro modely uložené v paměti, po kterých následuje procedura „commit“, která nastavené množství kroků spojí do jediného výchozího modelu. Stejně tak by mělo být možné nastavit, jak často bude docházet k zálohování modelů na disk a kolik verzí takto vzniklých souborů se eviduje, než dojde k proceduře „commit“ tentokrát na disku. (Může se jedna například i o časové intervaly).
Předchozí odstavec ještě jednou a srozumitelně: Data jsou v systému ve dvou fázích: na disku a v paměti. Verzování v paměti je rychlejší a může být složeno z drobnějších kroků. Verzování na disku je pomalejší, ale výpadek proudu již data neohrozí. Proto by mělo docházet k pravidelnému kopírování dat z paměti na disk a verzování by mělo probíhat současně v paměti i na disku, ale na disku úměrně méně často.
Vše výše uvedené, by však uživatele nemělo znepokojovat a tato činnost by měla být před ním do značné míry skryta. Uživatel by měl vidět pouze jeden model, který může samozřejmě kopírovat, mazat, přesunovat (přejmenovávat), ale neměl by rozpoznat, zda je tento model na disku, nebo jen v paměti. Zůstává ovšem samozřejmě ta možnost, že bude moci snadno listovat ve verzích modelu a v případě ukončení práce s modelem, nebo i během práce bude moci sám ručně zahájit proceduru „commit“.
Z pohledu uživatele budou v systému přítomny tři entity, které on může vzájemně spojovat. Jde o model, o funkční okno a o editor. Tyto tři entity by měly být v systému nějak reprezentovány. Na začátku úvah o FW byly zmíněny barvy – tedy typy modelů, oken a editorů, jež lze vzájemně kombinovat. Jak se budou zmíněné entity prezentovat záleží na konkrétním provedení, ovšem uživateli by měla být dána možnost otevřít FW, umístit ho nad konkrétní model a připojit k oknu editor.
Ovšem tím výčet možností zdaleka nekončí. Uživatel by totiž mohl vzít model, a použít na něj editor s jednorázovou účinností na celý model. Vzniklý upravený model by mohl snadno nahlédnout funkčním oknem a editor připojený k tomuto oknu by po dokončení úprav mohl nabídnout model k dalšímu zpracování, nebo uložení na disk.
Příkladem může být streamové zpracování zvuku. Modelem nechť je zdroj zvuku (mikrofon) a prvním editorem například odstraňovač šumu. Dalším modelem nechť je množina obrázků. Oba zmíněné modely budou vstupovat do editoru, který je spojí a výsledkem bude model video. Mezi model řady obrázků a video editor může uživatel umístit FW, které bude pouze zobrazovat právě probíhající obrázek. Čili uživatel se snaží okomentovat svoje fotografie z dovolené a vytvořit z nich video.
Tato vizuální práce s modely je moderní obdobou unixového shellu (přesměrování, roury, …), a není to poslední funkce shellu, kterou se nechávají FW inspirovat. Po tomto nástinu je třeba se detailně podívat na všechny zmíněné entity a probrat jejich možné funkce.
Jak již bylo řečeno, editor nabízí funkce specificky použitelné na nějaký model nebo jeho komponentu. Ovšem mohou existovat i editory, které spojují několik modelů v jeden a nebo naopak rozdělují jeden model na vícero. Jedny by bylo možné nazvat slučovači (joiner) a další rozdělovači (splitter). Existují také editory, které mohou samočinně (skriptovaně) pracovat na modelu, bez zásahu uživatele. Těmto editorům se říká stream editory.
Další neopomenutelnou variantou editoru by byl takzvaný kompozitér (composer). Vstupem do něj by bylo více modelů a uživatel s nimi pak zachází jako s komponentami, různě je vůči sobě časově nebo prostorově posunuje (za přispění pohledu skrze funkční okno) a nakonec sám určí jaký model, nebo modely se z nich mají stát.
Jeden editor může samozřejmě zvládat všechny výše zmíněné varianty editování, ale také nemusí. Spojování modelů s editory a jejich tok by mohl být graficky znázorněn šipkami mezi spuštěnými editory. Inspirace typicky programy Softimage nebo Blender. Což neznamená, že to nejde i jinak.
Modely jsou uloženy v paměti a je-li tak editor nastaven, jeho editací vzniká upravená verze modelu, která opět leží někde v paměti. Editory by měli umět zpracovávat i modely, které se chovají jako proudy (streamy) a tudíž nemusí být vždy přístupné jako celek. Tedy i prázdný model může mít nějakou dopředu neznámou délku a editor čeká než se v modelu objeví nějaká data, aby je mohl zpracovat a přeuložit.
Formát XML je vhodným formátem pro řadu editorů a pro zobrazení uvnitř oken, ale modelem by mohl být i nějaký systémový zdroj. Modelem by v unixovém pojetí mohl být jakýkoli soubor. A konečně modelem je i samotný systém.
Na model systém je možné podívat se skrze specifická okna a použít specifický editor. Vzniká tak uživatelské rozhraní implementující již zmíněné funkce: zobrazení třech základních entit v různých fázích jejich použití a práci s nimi. Systém je tedy zvláštním případem modelu. Jeho komponentami jsou například pevné disky, DVD, datum a čas, síť, zvuková karta, prostě vše, s čím by uživatel chtěl kdy pracovat. Vybrané FW, kterým se na tento model uživatel podívá, bude vlastně grafickým uživatelským rozhraním. Zvolený editor pak nabídne množinu funkcí pro práci se systémem.
Základní vlastnosti funkčních oken již byly představeny, ovšem díky tomu, že FW jsou vcelku autonomní, lze snadno rozšířit jejich schopnosti. Například kromě změny velikosti a polohy na pracovní ploše (jde o plochu funkčního okna, které zobrazuje systém), lze snadno přesunou FW na jinou obrazovku, rozšířit jeho velikost na více obrazovek, nebo ho přímo směrovat na jiný počítač.
Za zmínku ještě stojí propojování funkčních oken. Je docela snadno představitelné, že nastane případ, kdy uživatel bude chtít pouhým vybráním jedné komponenty měnit obsah jiného okna. Bude například vybrán den v kalendáři a jiné autonomní okno zobrazí detaily tohoto dne. (Zde se již naráží na problém, jak mnoho funkcí a modifikací zobrazení bude dáno na starosti funkčním oknům a kolik se toho nechá na samotné editory.)
Zvláštním případem pohledu na model jsou pohledy typu dialogu (nastavování, konfigurace pomocí grafických prvků).
Výchozím předpokladem je, že konfigurace čehokoli je uložena v konfiguračním souboru (tedy model typu konfigurace). Například je třeba nastavit vlastnosti oken nebo editorů nebo jejich často používaných celků (kterým se říká aplikace, viz níže). Problematiku lze rozdělit na dvě části – problém zobrazení konfiguračního modelu jako dialogu a problém zobrazení konfiguračních modelů jako průvodce.
Obsahem modelu jsou samozřejmě proměnné, které lze nastavovat, ale současně i jejich jméno, stručný popis a hodnoty, kterých může proměnná nabývat. Vizualizace takového modelu se pak sestává z problému, jak rozmístit proměnné, aby spolu funkčně souvisely, jaký typ výběru pro proměnnou nastavit (radio buttons, check box, list atd...), které proměnné jsou důležité a které jsou spíše pro fajnšmekry. Jinak řečeno zkušený uživatel může editovat konfigurační soubor ručně, ale ostatním by více vyhovoval přehledný dialog.
Všem by se ale hodil inteligentní dialog, nebo průvodce (wizzard), který rozpozná i které kombinace hodnot proměnných jsou relevantní či vůbec možné a jakým způsobem se kombinace proměnných účastní na výsledku konfigurované funkce. Právě proto je XML formát nedostačující (možná). Mezi proměnnými by měly být uvedeny i jejich vzájemné závislosti (jakási inverzní algoritmizace vůči funkci, která se právě konfiguruje). Dialog, či průvodce by měl nejen nějakým způsobem ukazovat jak se ta či ona změna projeví ve výsledku, ale zároveň, jak nastavit určité proměnné, aby se došlo ke konkrétnímu výsledku.
Zkonfigurovaný editor a okno a spojení těchto dvou entity může být pro uživatele jednou a provždy dostačující rámec pro práci s typem modelů, které používá. Tak vzniká aplikace.
Aplikace je vlastně funkční okno s editorem (nebo editory), které je postačují na dlouhodobou práci s mnoha různými modely. Uživatel by měl mít možnost tuto kombinaci nějak uschovat a vyvolávat v případě potřeba třeba i mnohonásobně. V paměti může jít o model, který udržuje informace o použitém okně a editoru a o jejich konfiguraci. Tento model pak zobrazí jako komponentu FW, které právě zobrazuje systém.
FW zachytává vlastně všechny události, které uživatel nad tímto oknem provede (stisk myši, táhnutí myši, události klávesnice atd...). Systém by se měl dát nakonfigurovat tak, aby uživatel mohl za každou událost dosadit jakoukoli klávesu nebo kombinaci kláves (nebo myši). Ovšem nastavuje tak pouze to, jaká událost bude stiskem kláves nebo myši vyvolána.
Z principu je jasné, že FW bude zachytávat veškeré události (minimálně od uživatele, možná i od systému) a bude je překládat na standardní události, kterým rozumí editory (vyber komponentu, přesuň komponentu, vyvolej editor na tuto komponentu...).
Posledním zajímavým tématem jsou standardní výstupy, které může produkovat editor. Editor, jak bylo zmíněno, může operovat nad stejným modelem, který je zobrazen v okně a současně může přeposlat model jinému editoru, nebo ho uložit. Přeposlání je jakýsi výstup z editoru. Tímto výstupem nemusí nutně být model stejného typu jako model nad kterým je právě operováno (editor typu splitter). Navíc ovšem editor může hlásit různé stavy svoje, nebo modelu. Těmto výstupům se říká standardní.
Jsou to kupříkladu informace o průběhu nějaké funkce, informace o výsledku funkce nebo například chybové hlášky a podobně. Uživateli je dána volnost, jak s těmito výstupy naloží. Ovšem v případě, že by bylo i chybové hlášky možno ignorovat, pravděpodobně by editor měl mít možnost jak ošetřit svou další práci nad modelem.
Po přečtení je vám asi jasné, že jde o zaznamenaný proud myšlenek a ne o ucelenou představu, ale základní postřehy jsou asi celkem jasné: Bude-li mít uživatel v ruce myš a v hlavě mozek, bude počítač pracovat pro něj a ne naopak. Aplikacím je sebrána možnost vnucovat uživateli svou vůli, svoje ovládání, své formáty. Přitom je v základních rysech možné toto GUI s funkčními okny implementovat třeba na Linuxu.
Pokud jste se prokousali až sem, velmi by mě zajímal váš názor, postřehy i připomínky nebo návrhy. Zjednodušený náhled, jak by asi FW mohly vypadat je zde: GUI Function Window. Následující otázky jsou jistým vyjádřením toho v čem by z principiálního hlediska mohly být problémy:
Tiskni
Sdílej:
FW a editor je něco úplně jiného. FW se stará pouze o zobrazení (plus výběr komponent či vkládání pomocných čar, jakýchsi fólií, nad zobrazený model), zatímco editor se již o zobrazení nestará a plní jen editovací příkazy.
Je to tak trochFW a editor je něco úplně jiného. FW se stará pouze o zobrazení (plus výběr komponent či vkládání pomocných čar, jakýchsi fólií, nad zobrazený model), zatímco editor se již o zobrazení nestará a plní jen editovací příkazy.
Je to tak trochu rozsekaný a hybridní model-view-controller. Cílem je standardizovat model, aby k němu mohl kdokoli, kdykoli a jakkoli (žádné uzavřené formáty a problémy konverzí) a standardizovat práci s tímto modelem (klávesová zkratka pro „zoom“ vyvolá zoom v jakémkoli okně).
V reakci na Váš příklad bych byl ovšem opatrnější, protože FW jsou opravdu spíš jen o ovládání desktopu, než o nasazení v databázích, distribuovaných objektech, nebo informačních systémech. Mel bych ale jiný příklad: Dejme tomu, že budete psát bakalářskou práci. Modelem je textový dokument. Jedním FW se na tento model podíváte jako na kontinuální text s XHTML značkami, kterým budete současně chtít editovat a proto si na toto okno „přilepíte“ editor textu, který vám umí doporučovat dokončení tagů a hlídá i syntaktickou správnost. Současně si chcete být jist, že píšete správně česky a přilepíte na toto okno ještě jeden editor kontrolující pravopis. Dalším oknem si otevřete tentýž model, ale nyní v zobrazení výsledného dokumentu. Ještě jedním oknem se podíváte jak vypadá současná osnova, seznam použitých obrázků, tabulek a grafů, citace a podobně. A hlavně si otevřete okno, které vám bude ukazovat kolik ještě znaků musíte napsat, aby jste splnil limit. u rozsekaný a hybridní model-view-controller.