Názory k článku GNOME 47: vlastní nastavení barev, lepší škálování a nové dialogy

Přehlédl jsem něco, nebo je Binary jen podmnožina kalkulačky?

V GNOME Circle je celkem znat tendence mit milion malickych aplikaci ktere delaji jenom jednu vec. Tohle je jenom ponekud extremni priklad.

trend je jasný, ovlávání maximálně upravit pro matlací displeje. Ve finále ale nepřináší nic, kvůli čemu bych tomu chtěl dát znovu šanci.
Nemožnost přistoupit k Firefox Sync je pro Web dosti omezezující, snad se jim to podaří zprovoznit.

To rozhodne, dodam jeste dalsi drasticke omezeni - nepodpora rozsireni (tj. zadny manazer hesel, vlastni blokovac reklam, gesta mysi, atd). Ja bych Epiphany i rad pouzival vic ale je to zatim prilis nepohodlne.

Ovsem nechci znit prilis negativisticky, nejaka podpora vznika a pracuji na tom, akorat posledne co jsem to zkousel nefungovalo nic co chci, takze je jeste potreba cekat.

1. 10. 2024, 10:18 editováno autorem komentáře

@Jyrki ...pro matlací displeje. Souhlas. Kde zmizely pokusy ovládat komp hlasem? (Samozřejmě v místech bez lidí, na doma.) Koncem 90. let jsem měl komp s OS2-Warp od IBM a šel částečně ovládat hlasem (natrénoval se na hlas). Jednoduché povely typu: mail, zavřít, AmiPro, spread-sheet a podobné fungovaly.

Ved dneska mame Siri, Hey Google, Bixby, Cortana... a ludia na to povacsinou kaslu.

Kaslou, protoze to jednak nefunguje, druhak tlaciko je o 3 rady rychlejsi a efektivnejsi. Ostatne ... spousta "zanovnich" aut to ma taky. Zkousel si to nekdy? Nez tomu vysvetlis, ze chces zmenit teplotu a jak, tak to rukou tocitkem nastavis asi tak 1000x (ano, chapu ze v tesle muze byt efektivita srovnatelna, kdyz kvuli nastaveni musis projit 10 urovni menu na patlacim lcd).

Proc bych se mel dohadovat s nejakou pixlou? Totez jsou plechovy huby na telefonu = obratem pokladam, a fima jde na blacklist, on nich si nekoupim ani spendlik.

Tesla má výhodu, že stejně jako např. iPhone ji má spousta lidí. Takže jsou na to vylepšení od třetích stran (jen pár modelů a má je milióny zákazníků). Např. pro tu Teslu jsou tlačítka na volantu, jak je člověk zvyklý u ostatních automobilek.

Dialog pro vyber souboru - tak to je jedna velka vec, co mi v linuxu vadi (a ve winech taky). pokud se clovek neomezuje jen na software skupiny (KDE, GNOME), tak to vypada pokazde jinak, ma to jine chovani, a neni problem behem prace narazit na 4 ruzne typy toho sameho.

A i tak, je to pokazde hruza. Casto si dialogy nepamatuji posledni misto, a pri praci v ruznych programech musim tu samou cestu najit vicekrat, nektere programy tvrdosijne trvaji na male velikosti dialogu i kdyz ja ho potrebuji vetsi, nejake sjednoceni zalozek s cestama taky nefunguje na 100 %.

Zkousel jsem kdysi nejake programky na sjednoceni, ale veci to spis rozbijelo nez zlepsovalo.

Ne ze by to bylo ve windowsech lepsi.

A přesně to řeší XDG portály, aplikace mají uniformní rozhraní kterým si vyžádají spuštění dialogu a o výběr dialogu se stará desktop.

Přesně tak, pokud aplikace volá XDG portál místo přímo konkrétní dialog, otevře se dialog, který má dané prostředí nastavené jako výchozí a je tak pro všechny aplikace, které portál používají, stejné.

Navíc díky tomu aplikace dostane přístup až k vybraným souborům a nepotrebuje se dostat k celému disku, což umožňuje plný sandboxing.

Jirko, tolik k teorii, kdyby to bylo tak jednoduché...!

Ve skutečnosti jsou aplikace, které XDG ignorují a používají svůj dialog. Třeba i ten firefox je třeba přesvědčit, že opravdu nechci ten jeho... Obvykle na tento problém narážím u GTK aplikací.

Já netvrdím, že to používá každá aplikace, jen, že na to existuje řešení. Jestli to aplikace používá nebo ne, je pak na jejích autorech. Firefox by měl portál výhledově taky podporovat, pro některé věci ale požaduje udělení přístupu k celé složce, což daný portál zatím neumí, proto používá ten z GTK, ale řeší se to.

Jenže, pokud potřebuju dialog customizovat, tak mám problém. Nebo to nějak jde?

Jen to co umožňuje portál -> https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.FileChooser.html

na stranu druhou, tohle není potřeba nějak často, konkrétně mě teď nenapadá žádný rozumný use case. Byl by nějaký vhodný příklad?

Třeba náhled nad rámec toho, co umí standardně? Donedávna neuměl ani obrázky. Windows Explorer už umí třeba i 3D objekty a naše firma to využívá (CAD/CAM software). A pak různé checkboxy a přepínátka, ve Windows je to běžné. Je otrava, aby pak vyskočil druhý dialog pro parametry otevření nebo uložení (např. síla JPG/PNG komprese)

1. 10. 2024, 17:28 editováno autorem komentáře

Ja si myslim ze si do systemu mozete dat vlastnu implementaciu backendu daneho portalu ak chcete.

Hezký, těším se, až 47 dorazí do Tumbleweedu a Fedory.

Napadl mě jen jeden volně související dotaz, možná budete vědět..
Když se pouští QT aplikace v GNOME s Waylandem, tak se zobrazí úplně bez stínů a rámečků okolo oken a dialogů.
Což je činí s dnešními bílo-bílými schémátky velice špatně použitelné.
Jediný workaround, co jsem našel, tak je nastavit env. QT_QPA_PLATFOR­M=xcb. Tím se vynutí ne-nativní vykreslování pomocí XWaylandu, a vypadá to v pohodě.

Přiznám se, že nemám úplně jasno ohledně toho, kde je problém. Našel jsem sice pár různých postů x let zpátky, ale nejsem si jistý. Jestli jsem to pochopil správně, tak je tam nějaké principiální nedorozumění mezi přístupem např. KDE s Kwin a GNOME s Mutterem, kdy jeden používá dekorace v kompozitoru a druhý zásadně ne.
Víte o tom něco víc, příp. je tam nějaká tendence se dohodnout a tohle do budoucna vyřešit?

GNOME kreslí jen client side dekorace a odmítá implementovat Wayland protokol, který obsahuje i server side dekorace. Tedy ne-GNOME aplikace mají smůlu, resp. musely by si stíny kreslit samy, často pak končí jiným vzhledem (tlustší/tenčí, okolo ze všech stran stejně tlusté vs posunuté dolů, ...)

V GNOME na Waylandu si celé okno včetně dekorací vykresluje sama aplikace, respektive toolkit, který používá, v tomto případě Qt. Ve Fedora Workstation to už máme nějaký čas pořešené a Qt aplikace mají v GNOME normální dekorace a stínování. Do upstreamu by se to mělo dostat jako QAdwaitaDecorations ve vydání 6.8, tedy brzy.

Aha. Určitě to vyzkouším, teď jsem se díval na github toho projektu, jsou další informace.

Fedoru mám jednom test. stroji, ale jak jsem to hrnul z verze na verzi, myslím, že tam ještě bude pořád někde nastavené QT_QPA_PLATFORM jako workaround. Taky musím zkontrolovat, jestli jsou tam všechny potřebné balíčky. Není to totiž výchozí desktop instalace, ale server minimal, do kterého případně přidávám menší skupiny.
Každopádně moc díky za osvětlení a informace o případném řešení.
Kdyby to zabralo, tak to bude určitě posun. Přestože budu mít asi většinu aplikací v GTK, jsou nějaké v QT, které rád používám jako Okular, KeepassXC atd.

Jaký je vlastně aktuální stav běhu jednotlivých desktopů na kombinaci Wayland+GeForce? Nějakou dobu jsem to nesledoval, ale už GNOME s Waylandem na GeForce funguje plně použitelně, případně pro jaké generace GPU/ovladačů?

KDE(Sway, microcompositor Valve atd)+Wayland+Nvidia je ok.
GNOME47 má regresse ve výkonu. Alespoň u distribuce, kde jsem si testl GNOME47.
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2052913
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-560/+bug/2081140

Co se týče podpory VRR, více monitorů a VR, to nevím.
KDE má všechno dříve než GNOME.

Jak je na tom v současné chvíli VAAPI v browseru s HW dekódováním, tam byla taky regrese, to také nevím.

Teď jsem zkoušel 4k video na YT bez HW dekod. a překvapilo mě, jak to má malou zátěž na CPU. Je sice větší než s funkční HW dekod., ale daleko menší než před měsícem, dvouma.

Otázkou je, když vynutím HW dekoding, zda to bude stabilní. Nějaký crash u FF se řešil a vyřešil.

1. 10. 2024, 19:31 editováno autorem komentáře

Dle borca na fóru Nvidie má být VAAPI v browseru funkční(ne ve výchozí instalaci).
Proton na Waylandu/XWaylandu mi běhal také již bez problémů.

Na Ubuntu 24.04 s nVidia 4060 ve Wayland musím mít vypnutý Night Light, jinak desktop zamrzává, a to i s poslední beta verzí ovladačů, viz tohle issue.
Pak jsem měl nějakou dobu problémy s blikáním a performance v Google Chrome a VSCode, které se vázaly také na kombinaci Wayland + nVidia, ale teď koukám, že už se vše chová normálně. Nejspíš to vyřešil nějaký update Ubuntu (možná mutter).
Žádný další vážnější problém jsem nezaznamenal. Zkoušel jsem i nějaké hry ve Steamu na Protonu a bez problémů.

Pak jsem měl nějakou dobu problémy s blikáním a performance v Google Chrome a VSCode, které se vázaly také na kombinaci Wayland + nVidia, ale teď koukám, že už se vše chová normálně.

Tak abych ty ovladače nVidia nepřechválil, tak ten problem ve VSCode přetrvává (občasné blikání a "trhaný" kurzor např. v chatu nebo terminálu). Workaround je ELECTRON_OZONE_PLAT­FORM_HINT=auto

Tak on Chrome/Chromium, prohlížeče na něm postavené (Edge, Opera, Vivaldi, ...) a aplikace (Electron a na něm postavené třeba VS Code) způsobovaly pády linuxové virtuálky ve VirtualBoxu (emulovaná GPU) a na mém retro desktopu (Radeon HD 7850 2GB z r. 2012) způsobují zamrzání Windows 10 a 11. Používám workaround, že vynutím nepoužívat GPU akceleraci.

Je to hezké, líbí se směr. Tedy, mám problém s "quick setup" panelem (takovéto co se objeví když kliknu na ikony vpravo nahoře a můžu tam zvolit vypnutí nebo nastavit hromady věcí) - barevně prostě vybočuje, je to přebarvené a neladí to se zbytkem. Takže jsem si to musel upravit (vždyt když to bude barevné jako kalkulačka, tak je to ok).

Druhá věc je zvláštně umístěný spinner při kopírování v nautilu. Tak nějak to čekám kdesi vpravo nahoře a ono je to najednou vlevo dole - všiml jsem si toho až po nějaké době, do té doby jsem myslel, že to tam vůbec není.

Ten se zrovna v posledni dobe naraisoval dost. Byl v panelu vlevo nahore, pak vpravo a ted je nakonec vlevo dole. Podle me nejlepsi misto, ale taky ho tam neumim na prvni dobrou najit. Uz by to chtelo ustalit :-)

Na GNOME mě dost překvapila nějaká funkce, jež mohla být součástí nastavení obrazovky, kdy se mi párkrát stalo, že se okno aplikace dostalo mimo fyzickou obrazovku.