Summary: | Generate Xft.dpi from server dimensions at startup if not specified via configfile | ||
---|---|---|---|
Product: | xorg | Reporter: | Felix Miata <mrmazda> |
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | enhancement | ||
Priority: | medium | CC: | egdfree, jlp.bugs, vkrevs |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Felix Miata
2016-11-30 09:36:06 UTC
I disagree. There is absolutely no reason why it should be up to Xorg to bend over backwards to work around breakage _explicitly introduced_ by external developers. Xorg already provides a multitude of tools to expose DPI information (core API about display width and resolution, XRANDR information). If the toolkit refuses to use them, that's the toolkit issue, and users should complain with the toolkit developers (or work around the toolkit breakage in whatever way they can). (In reply to Giuseppe Bilotta from comment #1) > I disagree. With what exactly? > There is absolutely no reason why it should be up to Xorg to > bend over backwards Would it really be bending over backwards to provide a workaround for this particular GTK rudeness? > to work around breakage _explicitly introduced_ by > external developers. Not any ordinary developer, but an unavoidable rhinoceros herd. > Xorg already provides a multitude of tools to expose > DPI information (core API about display width and resolution, XRANDR > information). If the toolkit refuses to use them, that's the toolkit issue, Except that mere mortal users suffer from it and a conjunct absence of alternatives. > and users should complain with the toolkit developers I agree those that cause breakage should fix it, but just because it's the right thing to do doesn't mean anyone can expect it to happen. > (or work around the toolkit breakage in whatever way they can). A reasonable workaround is what this bug is asking for. > > I disagree. > With what exactly? Sorry, I mean I disagree with the idea of working around intentional regression in toolkits by introducing unnecessary complexity in Xorg. > Would it really be bending over backwards to provide a workaround for this particular GTK rudeness? I think so, yes. > Except that mere mortal users suffer from it and a conjunct absence of alternatives. There are alternatives, actually. Also, if mortal users suffer and don't complain or look for alternatives, that's again not an Xorg issue. > A reasonable workaround is what this bug is asking for. There are a number of possible workarounds. * distributions ship a patched version of GTK+3 that does the right thing; * a small LD_PRELOADable library is introduced that fixes the issue; * people stop using GTK+, given how uncooperative and user-unfriendly they are. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/509. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.