Vlákno názorů k článku
Emulátor Playstation 2 proti proudu: PCSX2 vypíná Wayland a stěžuje si na obrovské chyby
od byCx - To je trochu clickbait. Vývojáři si tam stěžují...
-
To je trochu clickbait. Vývojáři si tam stěžují na chybějící vlastnosti, protože používají více oken a oni je nemůžou na Waylandu pozicovat. Mají asi problém i s UI jako takovým, kde GNOME má nějaké standardy a jejich UI jde vyloženě proti nim. Wayland tam nikdo nevypíná, jen není výchozí, což je třeba něco, co oznámili i vývojáři Firefoxu, pokud by náhodou Wayland dělal problémy.
-
Nerozumim tomu, kde v te zpravicce vidite problem. Pokud v prostredi nefunguji vlastnosti a funkcionalita, kterou by clovek od takoveho prostredi ocekaval, je to asi problem. A uprime pozicovani okna je funkcionalita, kterou bych (alespon ja) ocekaval jako vylozene standardni funkcionalitu.
Navic uz v XOrg kazde prostredi zachazi s okny trochu jinak. Vzhledem k tomu, ze DE\WM jsou komunitni projekty tak si priznivci dane komunity nemusi niciho vsimnout. jenze ve chvili, kdy svuj projet pisete, tak aby nebyl zavysli na DE/WM pak casto narazite na tezko resitelne problemy, ve kterych jste vicemene sam - bo komunity. Pokud se to jich primo netyka, tak je to proste nezajima.
Komunity jsou alfou a omegou opensource a Linuxu obzvlaste. Jak toho dobrehe, tak i toho spatneho.
28. 11. 2023, 20:53 editováno autorem komentáře
-
> A uprime pozicovani okna je funkcionalita, kterou bych (alespon ja) ocekaval jako vylozene standardni funkcionalitu.
Pokial myslite len klasicky obdlznikovy displej, tak asi ano.
Pokial myslite displej, ktory moze mat iny tvar (kruh na hodinkach, oval na instrument clusteri pristrojovej dosky), tak uz moze vznikat problem, aby sa aplikacie nesnazili napoziciovat mimo viditelnu cast.
A potom tu mame zariadenia, ktore nemaju absolutny suradnicovy system: napr. taky headset. Tem ma niekde (0,0,0,0) a potom ide (-inf, inf) po 4 osiach.
Alebo iba taky stary dobry Doom compositor (https://www.youtube.com/watch?v=_FjuPn7MXMs).
Dovolit aplikacii pouzivat absolutne suradnice je zarobit si na dobry chaos.
Treba si uvedomit, ze protokoly Wayland tu nie su na to, aby sme urobili rychly fix na dnesny problem a kaslat na technicky dlh. Kazdy jeden protokol tu bude najblizsich 50 rokov, niekto to bude musiet udrziavat a bude to musiet fungovat s buducim zelezom.
Takze pozor na to, co je standardna funkcionalita a ako sa nou zabetonujete.
-
[ja]
Proto taky pisu o standardni funkcionalite prostredi, protoze na kazdem takovem zarizeni bych logicky ocekaval jine chovani. Vyvojari emulatoru PS evidentne necili svuj projekt na pristrojovy terminal ci hodinky. Pokud je (napr. ) Gnome schopne bezne fungovat i na vyse zminenych zarizenich, tak by to melo byt predevsim ono, kdo by mel v zavyslosti na tomto faktu prizpusobovat sve sluzby a davat to vhodnym zpusobem zpravovane aplikaci vedet - pokud to potrebuje. To je konec koncu jeho ucel.Krasnym prikladem je treba okenni parametr "gravity", ktery si jeden cas KDE* urcovalo jak se mu zachtelo, coz vedlo k padum NON-KDE aplikaci, pri manualni zmene jejich velikosti, protoze proste neocekavaly chovani KDE a kres;lily mimo kontext okna.
*Je to uz par let stara zalezitost, mam ten dojem ze z prvnich verzi KDE 3. Urcite to byl problem KWin. jestli ale jej zpusobovalo uz primo QT, to rict nedokazu. Na druhou stranu, sam z vlastni zkusenosti vim, jak blbe se stimto parametrem pracovalo.
-
No ale klasické obdélníkové displeje jsou stále jaksi dominantní a v dohledné době to nevypadá na nějakou zásadní změnu.
Průnik s aplikacema pro hodinky, nebo headsety je veškerý žádný. Takové aplikace musí mít celé uživatelské rozhraní navržené jinak. Jestli taková aplikace použije navrch i trochu jiné okenní api je už nepodstatný detail.A dál to už je úplný bizár. Opravdu se má brát ohled na 10 let mrtvé obskurní demo? Jestli je něco recept na technický dluh tak takovéhle úvahy. Podobné věci jsou cool demíčka, ale reálně se to k ničemu nehodí. A demíčka se dají nějak ohákovat, vlastně je to i součást zábavy.
> Kazdy jeden protokol tu bude najblizsich 50 rokov
Xka stihla beznadějně zastarat za necelých 40 let. Wayland už má 15. Kolik let zbývá jemu, než i jeho základní architektura neopravitelně zastará?
-
To obskurne demo bol ako priklad, ze predpoklady, s ktorymi niektori pracuju, nemusia byt spravne -- napriklad ze kompozitor nemusi mat absulutny, limiitovany 2d suradnicovy priestor, v ktorom pracuje.
Niektorym staci slovne vysvetlit, aby pochopili.
Niektorym treba ukazat (<= obskurne demo), potom pochopia.
Niektori nepochopia ani tak.
-
Aj vo VR sa daju pustat normalne 2d aplikacie. Je to proste textura orientovana v priestore, do ktorej sa zobrazuju.
Dalsi priklad: vzdialene aplikacie (RAIL, nie cely desktop). Na serveri sa vytvara headless session, kde framebuffer ma origin (0,0) a nema konecny rozmer. Jeho aktualny rozmer je identicky s rozmerom prenasaneho okna (t.j. surface klienta _je_ framebuffer).
-
Jo, pouštět se dají. Akorát používání je o dost horší v porovnání s normálním monitorem. Takže je tohle použití dost okrajová záležitost.
A u těch remote appek je ten framebuffer jen implementační detail. Na cílovém stroji má ta appka úplně normální pozici a rozměry. Jakékoliv požadavky na pozici nebo velikost okna stačí triviálně přeposlat.
Drhnout to začne až ve chvíli, kdy budu jednu appku chtít zobrazovat na víc vzdálených strojích. Ale tam těch problémů bude trochu víc. A zrovna u velikosti okna to najednou může vypadat skoro jako by ty požadavky posílala samotná aplikace. -
Jan HrachStříbrný podporovatelAle já používám standardní laptop se standardním obdélníkovým displejem tady a teď, a na něm zdá se Wayland nepodporuje základní a jinde běžnou běžnou funkci.
Ten váš argument ve stylu „NTP přestane fungovat až se bude lítat do vesmíru, tak radši nebudeme podporovat žádnou synchronizaci času, dokud se ten problém nevyřeší dokonale“ nechápu.
-
No a prave na migracii X11 -> Wayland mozeme vidiet, ze ked sa raz otvoria dvere, uz sa tazko zatvaraju.
Preto tie tazkosti so screenshotmi a screen castom: X11 klienti povazovali za dobry napad, ze si mozu zobrat obsah framebuffera, roky to tak fungovalo, tak kde je problem.
No problem je, ze v dnesnej dobe sa ocakava, ze lubovolna aplikacia nemoze len tak sahat na globalny framebuffer a musi ist cez nejake API, kde sa to da pouzivatelovi na vedomie, alebo schvalenie. Konceptualne je to podobne, ako ked prestal existovat globalny adresny priestor zdielany vsetkymi aplikaciami (ala DOS alebo Win16) a aplikacie dostali svoj vlastny virtualny; komunikovat s inymi musia cez IPC.
(A to uz nespominam to, ze globalny framebuffer s modernym hw uz nemusi existovat. Ked nejaky klient chce screenshot celeho desktopu, kompozitor mu ho musi poskladat offscreen rovnako, ako to vie urobit scanout hardware.)
A vidime, aky neskutocny problem tieto migracie su. Preto na to lietanie do vesmiru myslime uz teraz, aby sme nemuseli zase zacinat od nuly.
-
Jan HrachStříbrný podporovatel
> No problem je, ze v dnesnej dobe sa ocakava, ze lubovolna aplikacia nemoze len tak sahat na globalny framebuffer a musi ist cez nejake API, kde sa to da pouzivatelovi na vedomie, alebo schvalenie.
Ale já nemám problém s tím, že by to vyžadovalo schválení (to je naopak super), a že to nutně znamená, že bude potřeba nějaké jiné API. Já mám problém s tím, že to API neexistuje, případně existuje v několika nekompatibilních verzích, přitom se to už několik let tlačí uživatelům jako hotový výrobek a kdo na to upozorní je označen za „uřvanou menšinu“ a „chce spacebar heater“, a teď tu nově ještě někteří píšou, že to API ani jen tak existovat nebude, protože je to moc složité udělat správně aby to fungovalo s VR a Doomem a kulatými displeji a věcmi které možná přijdou v roce 2035.
-
Tak konkretne screenshoting a screencasting API existuje uz roky; akurat mnohi kritici, si to za tie roky neracili vsimnut a kritizuju dalej.
Podobne, nekompatibilne api (hovorime o screenshotoch, vsak?) -- kazdy kompozitor si urobil svoj prieskum, co je treba a co nie, preto tie api boli oznacene ako experimentalne (mnohi dodnes nechapu, co to znamena). Potom zobrali svoje skusenosti, a urobili jedno spolocne. Co je tna tom zle? Mali prist hned s dokonalym API, bez toho, aby mali nejaky feedback? To by zase boli kritizovani, ze rozhodli od stola a nesplna poziadavky...
Ako cokolvek, co skusia, je oznacene ako zle a nevyhovujuce -- lebo spacebar heating je velmi realny efekt.
-
Jan HrachStříbrný podporovatel
> Tak konkretne screenshoting a screencasting API existuje uz roky; akurat mnohi kritici, si to za tie roky neracili vsimnut a kritizuju dalej.
OK, díky moc za poučení, a pro ostatní kdyby taky nevěděli co univerzálního to podporuje, tak koukněte na flameshot. (a než existovalo, tak ti, co to požadovali, požadovali spacebar heating? :)
-
Tohle je pro Gnome typicky. Na jednu stranu se resi takovy veci jako ovalny displej. Na druhou stranu kdyz nekdo pozaduje moznost nastavit rychlost skrolovani koleckem mysi, tak se dozvi, ze je kteren, ze to neni potreba, za neco jako rychlost scrolovani Gnome nikdy implementovat nebude.
Gnome na totiz ma zabudovany vzorecek, ktery odvozuje rychlost scrolovani od uhlu pootoceni, vysky pismene v bodech a prumerne vzdalenosti oka od monitoru v zavislosti na vysce monitoru. A autor toho kodu je na svuj vytvor tak pysny, ze odmita cokoliv co by uzivatelum umoznilo rychlost scrolovani ovlivnit.
-
To ze Vy neco neocekavate jeste ale neznamena, ze to nekdo nebude pozadovat.
Ukolem spravce oken je sice spravat okna, to je pravda, ale take je potreba aby bral bral v potaz pozadavky aplikace. Autor takoveho programu fakt neni vsevedouci panbuh, aby byl shopen predikovat za jakych okolnosti a kdy bude nejaka funkcionalita potreba.
Samozrejme se muze stavet do role diktatora. Pak uz je otazkou jestli me (rozumejte autora timto diktatem dotceneho projektu) bude zajimat. Pak proste oznamim, ze pokud mozno ho nebudu respektovat a kdyz to nepujde, tak ani podporovat. A z tohoto hlediska mi prijde prohlaseni vyvojaru naprosto koser.
"Alfou a omegou open source jsou lidi, kteří na těch projektech pracují."
Kteri prave jsou nedilnou soucasti tech komunit kolem tech open source projektu. A rozhodne na to jak ten projekt vypada maji i velky vliv jeho uzivatele.29. 11. 2023, 00:27 editováno autorem komentáře
-
Uživatel si zvolí, že se nové aplikace mají otevírat na nejbližší volné polovině monitoru. Aplikace, kterou otevírá, ale požaduje dvě okna vycentrovaná uprostřed monitoru 5px od sebe o velikosti W a H. Co z toho má větší prioritu? Jsou to dvě pravidla jdoucí proti sobě, kde si jedno vyžádal uživatel.
GNOME je třeba také open source projekt se svou komunitou, která má stejné právo se rozhodovat, jakým směrem ho bude posouvat, stejně jako vývojáři aplikací.
Ono to je vesměs jednoduché. Pokud má mít desktopové prostředí nějaký řád, tak pravidla určuje prostředí a přizpůsobuje je uživatel. Pokud by pravidla určovaly aplikace, tak každá bude používat jiná menu, jiná dialogová okna, jiné barvy, jiné rozložení, jiná API pro přístup k hardwaru a tak dále.
-
> Co z toho má větší prioritu?
Tak ten odmítnutý pull request, o kterém vývojáři PCSX2 psali, to navrhoval jako doporučení. Takže zrovna priorita problém není.
> Pokud by pravidla určovaly aplikace, tak každá bude používat jiná menu, jiná dialogová okna, jiné barvy, jiné rozložení
Ono jim v tom nic nebrání. Uvnitř svého okna je každá aplikace svým pánem. A paradoxně čím víc základních funkcí nebude dostupných v nějaké standardní podobě, tím víc aplikací je bude implementovat tak nějak po svém a nekonzistentně.
I to chybějící absolutní pozicování jde jednoduše obejít. Prostředí tomu nemá jak zabránit. Řád tomu může dát tím, že tuhle funkcionalitu aplikacím poskytne samo. Jinak si to holt bude dělat každá jinak a po svém.
-
@JSH Když si ten "odmítnutý" pull request projdeš, tak zjistíš, že tam jsou vysvětleny důvody proč nebyl v současné podobě mergnutý. Je tam třeba hezká část o tom doporučení:
As written here before, the problem with hints is that as soon as someone successfully uses them, they start to rely on them, which then makes all other compositors that ignore the hints be "buggy" with the application from the end user perspective.
A jedna reakce:
I would expect a compositor that implements this protocol to also honor the hints if possible, otherwise the compositor shouldn't implement that protocol at all - maybe that is worth clarifying.
Takže z doporučení je najednou něco, čemu by se mělo vždy vyjít vstříc. Ty argumenty tam nejsou špatné, ale chápu, že ne každý to vidí stejně.
Fakt jde jednoduše obejít, když ho ten protokol nepodporuje?
-
[byCx]
Pokud si to tak uzivatel preje, pak by jednak dane prostredi by melo dat aplikaci vhodnym zpusobem vedet, ze nemuze jeji pozadavek obslouzit a z jakeho duvodu. Pokud se prostredi pokusi aplikaci nasilne (nebo rovnou bezohledne) vnutit sva pravidla vede to k obtizne resitelnym behovym chybam. Navic takovy pristup taky vede k tomu, ze se vyvojar dane aplikace absolutne nemuze spolehnout na to, co na danem typu zarizeni funguje a co ne.
A jednak spravce oken stejne musi delat vyjimky. Nemate jen jeden typ top-level windows. Nektere museji byt zobrazeny urcitym zpusobem uz z jejich povahy. napr. okna notifikaci.Jindy si zas aplikace usmysli, ze zrovna ted musi byt maximalizovana nebo hozena do fullscreen modu. A do toho se vam zacne na vrch stacku protlacovat okno ktere ma navic i pevnou sirku okna - napriklad nejaky dialog. Dalsi takovou srandu napr u dlazdic je otazka vetsiho mnozstvi otevrenych oken. Vsechna okna maji nejakou minimalni velikost, danou treba jejich layoutem a minimalni velikosti widgetu. Pokud to spravce oken nerespektuje, hrozi velmi realne riziko, ze neco zacne kreslit mimo kontext - a prusvih je na svete. Mimochodem, kdyz jsme u toho, ony i ty Gnome aplikace spustene na jinych spravcich maji zase sve pozadavky a ne nektere z nich musi proste WM reagovat jinak skonci treba s chybou BadWindow. Tohle se treba dost blbe hleda a jako dokumentace Gnome je v tomto ohledu... no dost skoupa.
Takze stejne musi spravce musi respektovat pozadavky aplikace, priorizovat, a neustale resit podobne radosti stacku oken a ne vzdy proste se mu dokonale musi darit dodrzet zvolenou strategii zpravy oken (napr. nejaky typ dlazdicoveho usporadani - volne plovouci okna to maji nejednodussi :-) ) Neni to snadne, to nepopiram, ale spravce oken by opravdu nemel byt diktator, jako spis strateg, ktery dela maximum proto, aby pokud mozno vyhovel co nejvetsi casti aktualnich pozadavku. To plati i pro dlazdicove zpravce oken, ale samozrejme zavisi na autorovi (autorech) daneho programu.
29. 11. 2023, 01:22 editováno autorem komentáře
-
@D.A.Tiger Samozřejmě je WM bude obsluhovat požadavky na notifikace a dialogová okna, ale nutně nemusí vycházet vstříc úplně všemu, co po něm aplikace chce. Navíc v tom v tom PR je vyloženě napsáno, že většina problémů neleží na bedrech protokolu jako takového, ale na QtWayland. Desktopové prostředí se pak může snažit jak chce, ale pokud se Qt tváří, že něco udělalo, ale ve skutečnosti to jen ignorovalo, tak se s tím nic dělat nedá. V tomhle případě Qt omezuje i možnosti ty problémy nějakým způsobem obejít. Konkrétně tam je třeba zmíněné, že není možné přepnout na X v době, kdy aplikace ví, že běží na Nvidia kartě. Ono to je logické, protože ten úvodní handshake, kdy se tohle řeší, se děje dlouho před tím, než se spustí první řádek samotné aplikace. Pokud si zvolím knihovnu, která nefunguje správně a někteří výrobci grafických karet konzistentně ignorují vývoj projektů, které ten jejich zázrak používají, tak takovéhle problémy vznikat budou.
Původně jsem ale reagoval na dost negativní tón zprávičky, která obsahuje i vyloženě lži jako "velmi málo pokroku v poslední dekádě" nebo "rozbitou/zabugovanou funkčnost prakticky pro jakékoli běžné scénáře použití". To druhé je dokonce vyvráceno uživateli, kteří to na Waylandu používají a pod to odkazované PR napsali. To jen abych odpověděl na otázku, kde je v té zprávičce problém.
-
Nechápu o co se snažíš. Prostředí řeší notifikace nějakým způsobem, který je společný pro všechny aplikace. Já si pamatuju dobu, kdy to tak nebylo a měl jsem na desktopu notifikace, kde jedna vyskakovala z dolního pravého rohu, další z horního pravého rohu a každá vypadala jinak. Notifikace vyskakují v režii prostředí. Vypadají stejně, vyskakují stejně a umlčují se stejně. To, kam si aplikace chce umístit své okno, s tím vůbec nesouvisí.
-
Jan HrachStříbrný podporovatel
V tom odkazovaném reportu máte pár příkladů. Většinou jsou to víceokenní aplikace, někdy využívající dva monitory.
Mimochodem ono to není o tom že „Já fakt neočekávám, že si aplikace budou vymýšlet kam se na ploše nastěhují.“ -- ten protokol je stejný když ho chce využívat uživatel. Třeba si můžete nadefinovat jak se mají okna po ploše rozházet podle toho co zrovna děláte.
A přidám jeden ze svých příkladů: když jsem s notebookem ve vlaku, letadle atd., kde je málo místa, a chci si číst třeba něco na webu, nejlíp se mi kouká na horní část displeje. Ale tam je lišta okna, menu prohlížeče, a následně často fixní (overlay při scrollování) menu té stránky (dobrý příklad jsou Google Docs). No a tohle řeším tak, že Firefox napozicuju tak, aby byl o 150px vyšší než obrazovka a přečníval nahoru. Ale tohle se blbě dělá myší, natož pak na touchpadu (musím okno chytit s modifikátorem, posunout mimo obrazovku, a pak roztáhnout; a když pak chci zvolit něco v menu nebo přepnout tab, tak to pak musím udělat znova). No a přesně na tohle mám zkratku - níže uváděný příkaz wmctrl. Ve skutečnosti je to modulárnější, aby to fungovalo s různými rozlišeními:
w=$(( `xrandr |grep -oE "current [0-9]+ x [0-9]+," | cut -d " " -f 2 | tr -d ,` + 4 )) h=$(( `xrandr |grep -oE "current [0-9]+ x [0-9]+," | cut -d " " -f 4 | tr -d ,` - 32 )) sleep 0.4 wmctrl -r :ACTIVE: -e 0,-40,-150,$(( $w + 30 )),$(( $h + 120 ))
-
Jan HrachStříbrný podporovatel
Moment, chápu správně, že ve Waylandu není ekvivalent
wmctrl -r :ACTIVE: -e 0,-40,-150,1200,1400
resp. tuto funkcionalitu si řeší kompozitor, takže to zase je různé pod GNOME, KDE, wlroots, někdo to nepodporuje atd.?
Mám klávesové zkratky, které mi nastaví okna na ploše, tohle nepůjde?
-
> Vývojáři si tam stěžují na chybějící vlastnosti, protože používají více oken a oni je nemůžou na Waylandu pozicovat.
Že si nějaká víceokenní appka zapamatuje rozložení a po startu bude vypadat tak, jak jsem ji vypnul? Tak jestli tahle samozřejmost jde proti standardům gnomu, tak je něco hodně špatně.
-
Nejde to proti standardom Gnome. Ide to proti tomu, ze aplikacia nemusi bezat na klasickom obdlznikovom desktope, vid moj komentar vyssie.
Rozlozenie medzi ukoncenim a novym startom aplikacie bude riesit session management; realnu geometriu ale aplikacia nedostane, pretoze vobec nemusi existovat, alebo moze mat viac suradnic, nez s kolkymi aplikacia pocita (a nedokaze spocitat sparse area, kde sa nic nezobrazi).
-
Jan HrachStříbrný podporovatel
> Aplikace si nemá co pamatovat svoje rozložení na monitoru. O to se má starat desktopové prostředí.
OK, na tom něco je. Tj. ty aplikace zmíněné v tom požadavku mají fungovat tak, že si to napoprvé uživatel roztahá po monitorech, a pak už si to pamatuje WM? Okna ale musí mít nějaký identifikátor, protože uživatel může jeden panel nástrojů zavřít a otevřít jiný, nebo si může hodit na chvíli obraz na fullscreen a pak bude chtít zase rozložení zpátky.
Nicméně nějaký způsob jak nastavovat velikosti oken jinak než taháním myší - ukázané wmctrl - by se hodil, čistě z uživatelského hlediska, třeba i pro to prvotní nastavení (abych třeba nemusel obcházet kiosky a přetahovat tam prohlížeče na správná místa a pak doufat že si to WM zapamatuje). (jenže pak už nemůžete aplikaci zabránit, aby si to wmctrl nespustila sama - alespoň dokud nebudou aplikace v brutálních sandboxech)
29. 11. 2023, 03:13 editováno autorem komentáře
-
Lenže bežnému užívateľovi je jedno, kto sa o to postará. Ja napríklad vôbec netuším, kto je zodpovedný za to, že mi vo Windows okná v rámci paint.net po reštarte aplikácie zostanú na svojom mieste. A úprimne ma to vôbec nezaujíma. Prečo by aj malo, veď to pokladám za niečo absolútne normálne. Pokiaľ toto vo Waylande (spoľahlivo) nefunguje a návrhy na implementáciu vyvojári vetujú (lebo chcú, aby GIMP fungoval na hodinkách a dívajú sa 50 rokov do budúcnosti), tak sa nedá diviť domu, že bežný užívateľ, ktorý na PC nepoužíva len browser sa do používania Linuxu moc nehrnie.
-
Tak ked to beznemu pouzivatelovi je jedno ako sa to udeje, tak preco sa stara do toho, ako to bude implementovane? Nema mu to byt jedno?
Bezni pouzivatelia sa kvoli waylandu nehrnu na linux? Zatial co pocas ery X11 sa len hrnuli, aby mohli rucne tunit konfiguraciu engligtenment wm a pisat shellove skripty s xdotool, az ich bolo treba vyhadzovat? Ci?
-
Tak uživateli je celkem jedno, jak je něco implementované. Ale není mu jedno, jak to funguje. A když to nefunguje, tak jde za vývojářem co mu přijde nejrelevantnější, bez ohledu na to, kdo za to doopravdy může.
No a tomu nejbližšímu vývojáři samozřejmě vadí, když za ním uživatelé chodí s problémy které jedna banda neřeší a druhá banda mu zase nedovolí, aby to mohl vyřešit sám. Obzvlášť pokud jde o základní věci, které všude jinde prostě fungují bez větších problémů.
-
Pointa predosleho prispevku bola, ze:
1) tvrdime, ze pouzivatelovi je jedno, ako je nieco implementovane, hlavne nech to funguje
2) napriek tomu sa dany pouzitel bije za konkretne riesenie.
Oba vyroky zjavne nemuze byt pravda. Bud je pravdivy prvy, alebo druhy, ale vzajomne sa vylucuju.
Co je horsie, pokial sa tvarime, ze oba sa nevylucuju, niektore aspekty pouzitelovi urcite budu jedno (napr. technicky dlh v bode 2), ale vyvojarovi nie, tak "jedna banda neresi".
"druha banda nedovoli" je zase nieco, co sa pozaduje po prvej bande; chapem, ze hrabanie sa v zdrojakoch nie je pre bezneho pouzivatela (keby som nemusel, ani ja to nerobim); ale prave to hrabanie v zdrojakoch a chapanie, ako veci funguju prinesu pochopenie, preco je to tak.
-
Z pohladu kompozitora su PCSX2 pouzivatelia; a biju sa za to, aby zahojili svoju aktualnu boliesku, pricom im je jedno, ze tym sposobia velku bolest niekomu inemu.
V daneho PR som pochopil obrovsku davku ignorancie o celej situacii; neskor, ked vysvitlo, ze dany vyvojar ani linux nepouziva, len pre neho nieco musi naportovat a zbuildovat, sa vela vysvetlilo.
-
Jan HrachStříbrný podporovatel
> napriek tomu sa dany pouzitel bije za konkretne riesenie.
On se tu někdo bije za konkrétní řešení? Kdo a jak by to řešení mělo vypadat a jaké řešení je to jiné?
-
Jan HrachStříbrný podporovatel
> Bezni pouzivatelia sa kvoli waylandu nehrnu na linux? Zatial co pocas ery X11 sa len hrnuli, aby mohli rucne tunit konfiguraciu engligtenment wm a pisat shellove skripty s xdotool, az ich bolo treba vyhadzovat?
Ano, přesně tyhle věci jsou důvod, proč Linux používám. Co dělají „běžní uživatelé“ je mi jedno, „běžní uživatelé“ taky třeba neprogramují, nekreslí v různých CADech atd., takže vlastně mít na Linuxu podporu pro tohle je zbytečné? :)
