Zaplaťpánbůh za ten nautilus. Ten koláč mi tak pil krev, že se nic neděje a ono celou dobu se plní malý koláček mezi ikonama někde v ...
"Modernější rozhraní" - taky mate pocit, ze programy v GNOMe jsou cim dal vic podivnejsi co se tyce pouzitelnosti? Priklad: Document Scanner. Scan se spousti tlacitkem vlevo nahore. Uklada se vpravo nahore. Novy dokument se dava vlevo dole. Takze prace pri skenovani spociva v litani mysi po cele obrazovce velvo vpravo dolu nahoru. Napoveda klavesovych zkratek zadna.
Opravdu to nekomu vyhovuje, nebo uz jsem stara paprika co nema rad zmenu? Mam pocit ze vsechno by melo mit menu nahore, a vsechno by melo byt dostupne minimalne z tohoto menu.
Mně to vyhovuje. GNOME HIG je jeden z mála projektů (FOSS i komerčních) kde se někdo opravdu zamyslel nad UX a použitelností na různých zařízeních různými lidmi (věk, zdravotní stav atd). A hlavně celou tu myšlenku srozumitelně popsali, vytvořili nástroje, a je docela radost v tom dělat nějaký vývoj. Není náhoda, že pravidelně téměř všechny appky ve Sklizni jsou buď GTK4 nebo Electron.
Příklad Document Scanner: scan se spouští tlačítkem vlevo nahoře (přesněji tam, kde "začíná" stránka; v RTL jazycích je celý layout naopak a tlačítko akce je tedy vpravo nahoře). Naskenuji si všechny stránky dokumentu (tj. krmím skener papírem a mačkám to jedno modré tlačítko, myš nikam nelítá) a když mám hotovo, přejedu po řádku přirozeně k tlačítku pro uložení PDFka, a následně pokračuji kurzorem na tlačítko pro ukončení aplikace.
Případně si zobrazím grafickou tabulku klávesových zkratek, která je ve všech HIG aplikacích jednotná a na stejném místě, a ovládám celou aplikaci pouze klávesnicí, což je jedna z věcí HIGem požadovaných.
Jsem naopak velmi rád, že klasická víceúrovňová menu z běžných aplikací vymizela. Pro mladého zdravého to překážka není, ale vidět tu frustraci jinak vitálního člověka, který kvůli drobné motorické dysfunkci najede do správného podmenu až na desátý pokus, protože vyjede kurzorem ze siluety a celý strom menu zmizí? Už ne, díky.
No tak ja musim skenovat vice samostatnych dokumentu, takze jezdim vlevo, vpravo, a jeste musim dolu nastavit novy dokument. Trochu jine pouziti, a uz je popsana idea za UX v pytli.
Problem je, ze potrebuju ten program mit maximalizovany, abych vedel jestli ma scan dostatecne rozliseni. Takze opravdu jezdim mysi po vsech koutech velke obrazovky.
Ja uznavam ze motoricky neni klasicke horni menu zadna vyhra, ale horni menu prece nevylucuje tlacitka na jinem miste. Horni menu + ikonky, to uz je s nama mnoho let. Akorat ja se treba v mnoha ikonkach spatne orientuji, text je pro mne prijemnejsi. Takze ve velkych programech obvykle ikonky ignoruju a pouzivam menu. A v menu byvaji (byvavaly) napsane i klavesove zkratky rovnou, coz dokazu rychle vyuzit.
Vyhoda horniho menu byla, ze tam byly vsechny moznosti programu.
Navic, Document Scanner to menu ma, sice jednourovnove, ale je tam, takze argument uplne nechapu. Ikonka tri carky.
Aha, a v tom menu jsou i keyboard shortcuts. Otazka proc se neukaze keyboard shortcut i pri najeti mysi nad tlacitko, jak byvavalo zvykem.
Jinak klavesove zkratky taky nejsou nejaka vyhra z pohledu motoriky. Same Ctrl+pismenko. Proc ne rovnou to pismenko? V tom programu se nikde nic nepise, krome nazvu souboru pri ukladani.
Fakt nemam pocit, ze by to bylo z pohledu UX nejak obzvlast vychytane. Asi jsem fakt zastaraly uzivatel, ktery ma bohuzel jine potreby nez si specifikovali v HIG.
Nejvetsi mor jsou moderni prostredi, ktere jako default nastavuji vzhled s ikonkama, ktere jsou vsechny sede, jednobarevne, apod. Tady defaultni design dost kulha. Asi to neni soucasti HIG, ale cele HIG jde pro me kvuli tomu do kopru. Ano, umim si nastavit jine tema ikonek. Akorat se to sype kdyz je jeden program QT, dalsi GNOME, a vypada to jak spanelska vesnice :)
Klávesové zkratky jsou naprosto nejefektivnější ovládání vůbec. Stačí, když chvilku dělám ve virtuálu kde je nemohu použít, protože mi je bere host. Hned to cítím.
Proč ne rovnou písmenko? Protože na klávesových zkratkách je kruciální, aby byli vždy stejné napříč aplikacemi, aby si to mohli dobře zapamatovat prsty. A jsme tu opět u HIG. Klávesové zkratky jsou vždy CTRL+písmenko, zkratky do menu vždy ALT+písmenko, atd.
Samozřejmě, není to dokonalé. Ale vyhovuje mi, že můj oblíbený systém jde správným směrem k HIG.
Takže kvůli každé drobné dysfunkci se má přizpůsobovat vše? To ale znamená, že je v pořádku trend, že se všechna tlačítka zvětšují na pětinu obrazovky, protože chudák, kdo to ovládá z telefonu nebo špatně vidí.
Nemělo by to sloužit primárně většině, která handicap nemá a případně umět i něco navíc pro lidi s postižením?
To ale znamená, že je v pořádku trend, že se všechna tlačítka zvětšují na pětinu obrazovky...
Přijde mi, že lidi, kteří mají pocit, že se tlačítka neustále zvětšují, zapomínají na to, jak ty aplikace vypadaly dřív. Tady jen ukázka toho, jak vypadal Nautilus před 15 lety. A tak je to u většiny aplikací GNOME. Dnes je poměr "obsah, s kterým člověk pracuje"/zbytek UI ve skutečnosti lepší.
No, zrovna mně asi více vyhovovalo to rozhraní z před patnácti let. ;oD
Osobně mi trochu překážejí ovládací prvky poházené po ploše, poněvadž se mi občas podaří kliknout naprázdno při přesunu kursoru - a pak se jen divím, co se zase spustilo. Když mi uteče myš z menu, obvykle to bývá bez následků (pokud se neukliknu tam, ale když už se pohybuji v nabídkách, dávám si pozor).
Právě kvůli horší motorice mám rád, když jsou ovládací prvky pohromadě.
Pro ovládání myší je pro mne (!) menu výhodnější (stejně tam ťapu klávesami). Různé klikací lišty a tlačítka rozesetá po ploše - zvlášť, pokud nereagují na [Tab] - mi tu práci komplikují.
Ale chápu, že na dotykové obrazovce je menu nešikovné...
https://regmedia.co.uk/2023/09/27/mantic-default-apps.jpg
Jaké je minimální rozlišení pro GNOME 45.xx? Já jen, že na fullHD to stále dělá tři tečky u názvu aplikací jako je na obrázku.
A celý Internet je plný toho, jak lidi hledají řešení jak zmenšit rozhraní GNOME.
21. 3. 2024, 10:05 editováno autorem komentáře
Zkusil bych zapnout přístupnost. GNOME Shell se tam dá přepnout do kontrastního módu, dá se tam zvětšit písmo apod. Pak to může vypadat úplně jinak. A pokud tam je skutečný problém pro lidi se zrakovým limitem, tak nahlásit.
U tohoto nezáleží na rozlišení. Designéři očividně nechtějí mít titulek delší než šířku ikony. Když se na ikonu najede myší, zobrazí se celý název. My máme v týmu člověka na přístupnost, ale on je zcelý nevidomý, takže na toto nenaráží.
Nějaké zdůvodnění je v merge requestu. Taky mě překvapilo, že by OpenH264 byl o tolik rychlejší než vp8enc, zvlášť když není hardwarově akcelerovaný, ale asi to mají vyzkoušené.
Ked som si kedysi cital k tomuto diskusia (v MR?), tak h.264 je len prvy nastrel, pretoze OpenH264 je vseobecne vsade k dispozicii, v buducnosti bude aj volba kodekov.
Ten OpenH264 je baseline-only enkoder, takze nic moc, ale zase moc procesor nezatazuje. VP9 enkoder nie je az taky bezny, Intel od Kaby Lake, AMD nevie VP9 encode vobec, vie len VP9 decode, aj to len tie, co maju Video Core Next (t.j. diskretna Vega nie, iGPU Vega uz ano).
Stejne to potrebuje klient ID, a zaridit si to neni pro BFU jednoduche.
Mne rclone s onedrive funguje dobre, a navod jak to zprovoznit je dobre popsany, ale je to celkem pruda.
Dokud to nebude ve stavu ze uzivatel napise login/heslo, a pak se v browseru objevi stranka onedrive kde odklikne potvrzeni pristupu, tak to bude jen pro znalejsi.
Hezky to mel udelany youtube plugin pro kodi. Vsechno zaridil sam, na obrazovce se objevila adresa na kterou se vlezlo v browseru a opsalo se 8 cisel do youtube pluginu. Jenze pak to google zmenil a ted je to obdobna pruda jak u onedrive - delani certifikatu, spousteni api apod.
Jeste by me zajimal nazor k hledani, pokud chci hledat podle typu sablon, to je to v tom strudlovem seznamu blizko hledaciho pole, myslite, ze se v tom dnesni clovek vyzna k jakym priponam se ty typy vztahuji? treba jsem hledal typ pro matrosku, ts a jine a cumel jsem do toho strudlu typu bez popisu ... radsi jsem napsal do pole treba .mkv nebo .ts nebo .pdf ale to muze byt i jen v nazvu s jinou priponou.
Co mě skutečně těší je, že by v Gnome 46 mělo být do gnome-system-monitor konečně přidáno, vedle využití procesoru a paměti také IO disku :)
https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/merge_requests/41