deloptes composed on 2016-11-30 07:30 (UTC+0100): I've not been, and adding it doesn't change anything. I'm not trying to start a server. I'm trying to alter the already running server from within the running server. The commands are all run on screen :0 in the instant case. Why does the first instance work as expected (as it has since it was KDE3 and probably KDE2 before) without specifying a screen? # man X(7) bash: syntax error near unexpected token '('. # man X no manual entry for X # tdecmshell --help-all only shows a displayname option, no displaynumber # tdecmshell --help-all Usage: kcmshell [Qt-options] [KDE-options] [options] module... Says nothing about server options. What is shown in http://fm.no-ip.com/SS/dpi108vs133.jpg is all from a single running instance of starttde, not some cut and paste hocus pocus. ??? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2016-12-01 01:17 (UTC+0100): >> That I know how to do when it's what I want to do. :-) 'man Xorg' works here. I think you are trying to teach me how to do what I already know how to do, which has nothing to do with the purpose of the exercise. On openSUSE, or on a Debian? (sidetracking....) Not exactly. Correct WRT :0. It has no effect on any program already open on :0, which is one half of the point of the exercise. The xrandr DPI change only affects programs opened after running it. I want before and after screenshots, purely for the purpose of showing someone what does and does not change as a result of a DPI configuration change. I succeeded in the bulk of reaching my goal, but inelegantly by using xterms instead of before and after tdecmshells I was expecting to be able to utilize. With tdecmshell I was expecting its own UI to demonstrate non-text effects on UI sizing, but most important was the text impact. Clearly. :-) - you can not run a I've been using multiple "screens" on the same display (:0, :1 and/or :2 running "simultaneously") forcing resolutions and DPIs for roughly a decade (mostly on test installations, rarely on my 24/7 systems). I only do it one of two ways though, never according to the man excerpt above, and never (except very occasionally very temporarily) via a dpi setting squirreled away in some DE's config file, and very very rarely using Xft.dpi (see: [2]). Either I run xrandr in a startup script[1], or via DisplaySize and/or PreferredMode in /etc/X11/xorg.conf*. [1] http://fm.no-ip.com/Share/Linux/setup (with a single # removed according to result desired) [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 https://bugs.freedesktop.org/show_bug.cgi?id=98909 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2016-12-01 08:50 (UTC+0100): OK, so lets see what might be learned from the screenshot (this is actually part of what the original exercise was/is about): A-an xterm was opened, and xdpyinfo reported the screen's apparent resolution and logical pixel density B-xrandr was used to change the current screen's logical pixel density while keeping the same resolution C-another xterm was opened, so that the impact of the xrandr command could be evaluated, in part by again using xdpyinfo Observations: 1-image sizes in (what there is of) UI remained unchanged 2-text size in the window decoration (titlebar) remained unchanged 3-other elements of the window decorations also remained unchanged (e.g. titlebar height) 4-xdpyinfo reports logical density increased from 108 to 133 5-text size in the new/2nd xterm application instance increased Conclusions: a-Window decorations seem to be part of an already running process, so are unaffected. b-Icon sizes (probably all bitmaps here, so sized in px) may be unaffected, but we can't be sure they are not from an already running process, so can't know whether they've been sized in px or pt (or other) c-Server's logical density increase caused text size increase in the new application instance (text sized in "physical" units: pt) d-Nothing other than text size seems to have been changed e-Other??? f-An increase in DPI on session start, all else being equal, can be expected to cause an increase in text sizes, if not in other screen elements g-Use of tdecmshell would probably provide more useful information for my original purpose than does an xterm As an additional exercise, compare the following (from separate sessions using configurations differing only in configured DPI (xrandr in startup script)). Note that the titlebar's right side's icons are larger, but not the left's (Firefox) icon, and that nothing within the application's web content area seems differently sized (movies, images and most web text are sized in px): http://fm.no-ip.com/SS/dt1680x108.png http://fm.no-ip.com/SS/dt1680x144.png -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2016-12-01 22:08 (UTC+0100): Did you happen to load the images below? They show at least one at same size (Firefox), and three not (upper right), the latter of which I suppose are entirely different icons used on account of the elevated DPI, but also could be SVGs rather than bitmaps. For my eyes, most icons are sized too small to describe their purpose (those in Gimp and LibreOffice are among the worst offenders), so that I either see them as flags, a target to hit with mouse pointer after seeing a tooltip that describes their purpose, or as a complete waste of space. I prefer meanings conveyed by words, but well recognize sometimes words simply cannot express that which is obvious in a picture. Not all environments make such an offer. I prefer that a DPI specification in most cases be made prior to, at, or as early as possible during Xorg initialization, in any event prior to a particular user's exposure to WM output. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2016-12-02 09:23 (UTC+0100): No way I'm going to bother with anything like that every time I switch displays. One of the reasons people use computers is to have things done automatically that otherwise would be difficult, awkward or even impossible. UIs, DEs and WP apps do the right thing with text by resizing automatically according to logical display density, as when a primary or only display is switched or otherwise replaced. Default themes should behave similarly, keeping icons appropriately proportionate to the accompanying text and surroundings rather than having arbitrarily selected bitmaps that take no account of display density or space actually available for them to fit into. Most of this thread really has nothing to do with $SUBJECT, the goal of which is to be able to demonstrate impact of a difficult to verbalize configuration change to someone in a different room, building or continent. Since no one has made his interest in this thread known, I must assume at least for the time being it is a difficult or impossible to solve problem, but the question remains whether there is any point in registering a wishlist bug to someday have it solved. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2016-12-02 19:56 (UTC+0100): I have my own site for those sorts of things: http://fm.no-ip.com/PC/displays.html http://fm.no-ip.com/PC/dpi.xhtml http://fm.no-ip.com/Auth/Font/fonts-pt2px-tabled.html http://fm.no-ip.com/Auth/Font/fonts-pt2px.html and more: http://fm.no-ip.com/Auth/wauth1.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2016-12-01 22:08 (UTC+0100): As shown by the two separate images of Firefox windows, the Firefox icon is obviously unchanged. It shrinks in proportion to the surrounding UI text as logical DPI increases, but remains identically sized on any given screen running any given resolution. OTOH, the minimize, maximize and close buttons, in TDE with default theme at least, are not the same in 108 DPI sessions as in 144 DPI sessions. XTerm isn't a TDE native app. Yet, it's UL, LL & LR icons stick with the 1680x1080 resolution, while the UR icons are as in Firefox, changing with DPI: http://fm.no-ip.com/SS/dpi108KonsoleVs108XTerm.png http://fm.no-ip.com/SS/dpi144KonsoleVs144XTerm.png My guess is that the UL, LL & LR icons are bitmaps that are not available in multiple sizes, or if available in multiple sizes, a limited number of them, and the spread between 108 and 144 isn't enough to cause a switch. Regarding the UR icons, it could be the only significant difference to the others is a greater selection of available sizes, while another possibility is that they are SVG images that scale nicely along with pt-sized text as logical density changes. That traditional typographic definition predates the Internet by at least my 6.5 decade lifetime if not more than a century. The Internet, through modern web browsers, has usurped that definition by making the pt in a web context a logical unit rather than a physical one: https://www.w3.org/TR/css3-values/#absolute-lengths In modern web browsers, the only time a pt fits the typographic definition is when logical and physical display density are in sync, and only if at 96 DPI. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

Michele Calgaro composed on 2016-11-30 18:15 (UTC+0900): Easier/workaround is as was done in the screenshot. What you suggest amounts to making screenshots of screenshots and somehow displaying the earlier as if realtime (without using an image viewer), as the purpose of the exercise is to demonstrate differing concurrent states to others, not the ability to display images that could have been constructed arbitrarily from some other environment. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/