Vlákno názorů ke zprávičce Qt 5.6 konečně přinese pořádnou podporu HiDPI od Pali - Takže si to už pomocou XRandR 1.3 bude...

Takže si to už pomocou XRandR 1.3 bude vedieť zistiť veľkosť v cm každého jedného pripojeného monitoru (output zariadenia), správne pre ne zrátať DPI/PPI a nastaviť škálovanie nezávisle pre každý jeden monitor? A potom to správne prekresľovať pri presune okna z jedného monitora na druhý, ktorý má iné DPI?

A čo urobia v prípade, že okno si nechám roztiahnuté cez dva monitory (ktoré majú rôzne DPI)?

Alebo to tiež pokašlali ako úplne tupí vývojari Chrome, ktorí DPI rátajú z cm rozmerov XScreen, čo je v skutočnosti obdĺžnikový "obal" okolo všetkých pripojených monitorov (čo má nulovú vypovedajúcu hodnotu pre monitory s rôznym DPI)? Btw, parameter --dpi pre xrandr nastavuje práve tútu zbytočnú hodnotu.

Už dávno lze v Qt zjistit rozlišení a rozměry každého jednotlivého monitoru a podle toho nastavit vlastní styly (včetně rozměrů prvků). Musí to udělat a pohlídat programátor. V Qt 5.6 se to jen zjednoduší na nastavení konstanty, podle které Qt přeškáluje styly samo a tím odpadne spousta kódu pro úpravu stylů. Pochybuju že to půjde měnit za běhu, takže dva monitory s různým DPI buď vyřeší programátor (lze už dnes). A nebo nic. Takže očekávám, že nastane přizpůsobení na primární monitor a dál nic.

Kvízová otázka. Jak by se měla chovat aplikace, která bude každou polovinou na monitoru s výrazně jiným DPI ?

> Pochybuju že to půjde měnit za běhu, takže dva monitory s různým DPI buď vyřeší programátor...

Takže opäť ďalšie nefunkčné riešenie hlavného problému. Už vidím ako každá jedná aplikácia si bude po svojom riešiť problém DPI... a samozrejme správne.

> Jak by se měla chovat aplikace, která bude každou polovinou na monitoru s výrazně jiným DPI ?

Predstav si, že máš dva monitory s rovnakou výškou (zobrazovacej plochy) v cm vedľa seba a oba majú rôzne DPI. Z toho vyplýva, že budú mať rôzny počet pixelov na výšku.

To správne riešenie je také aby užívateľ videl na oboch monitoroch to okno na správnych pozíciach a zároveň aby malo aj "správnu výšku". Teda z pohľadu renderovaných pixelov to okno nebude obĺžnik ale v tvare L (aby sa vykopenzoval počet pixelov).

IMO je ale tak velmi okrajovy problem (kolko krat bezne tahas okno cez viacero monitorov s vyrazne inymi DPI? Bezne LCD stoja par korun, a profici urcite nebudu riskovat artefakty kvoli roznym DPI), a navyse tak programatorsky narocny (navrhujes rozdelovat canvasy na regiony a v kazdom renderovat s inymi parametrami, a rozdelovat i rendering primitiv? Kolko max. regionov ma podporovat taka vec?), ze pochybujem ze by to komukolvek stalo za riesenie. A som si celkom isty ze sa najdu ludia ktori idealne chovanie vidia opacne ako ty...

To určitě není okrajovým problémem! Ve většině případů nemají 2 připojená zobrazovací zařízení stejná DPI.
Žádné kanvasy není třeba dělit, je třeba pouze renderovat na 2 (či více) zařízení dle DPI, viditelnost je možno řešit standardně ořezem renderované plochy.

A teď si představte ze máte kód který vezme nápis "ahoj" nechá ho vyrenderovat aktualnim systémovým fontem a z toho určí šířku v pixelech. A pak vytvoří ComboBox tak široký aby se tam ten nápis vešel. Jak se to má chovat při různých DPI? To co navrhujete je propojení vektorového a pixeloveho popisu obrazu a to bude vždy narážet na probemy. Už první verze javy dogmaticky prohlásila, že žádné pixely neexistují a že pro posis gui se budou používat pouze milimetry . Nakonec se od toho upustilo protože to bylo pomalé a neskutečně hnusné.

Ani a) ani b) ani c) nejsou spravne. Za d) je spravne, tedy skalou neni ani rozliseni (napr. px), ani skutecny rozmer obrazu (napr. v mm) ani DPI (tj. prepocet px a mm), nybrz vzdalenost obrazu od oka - viz. https://www.abclinuxu.cz/blog/mirecove_dristy/2013/2/vyvoj-linuxoveho-portalu-alebo-preco-to-este-nie-je-hotove/diskuse#88 .