man tdecmshell produces no manual entry. tdecmshell --help-all doesn't seem to show what I'm looking for AFAICT.
What I'd like is to open 'tdemshell xserver', then run an xrandr command to change DPI, finally run 'tdemshell xserver' to compare the before and after impact from the xrandr command. It doesn't work. The second tdecmshell run simply focuses the original window. Is there any way to do what I want? If not, is it a feature that might be added to 14.1 if I filed a feature request bug?
For now what I have to do as workaround is as shown here (using xterm) :-(: http://fm.no-ip.com/SS/dpi108vs133.jpg
Felix Miata wrote:
xserver
In your example I don't see how you are passing the display number to xserver command
All of the X servers accept the command line options described below. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
:displaynumber The X server runs as the given displaynumber, which by default is 0. If multiple X servers are to run simultaneously on a host, each must have a unique display number. See the DISPLAY NAMES section of the X(7) manual page to learn how to specify which display number clients should try to use.
deloptes composed on 2016-11-30 07:30 (UTC+0100):
Felix Miata wrote:
xserver
In your example I don't see how you are passing the display number to xserver command
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?
All of the X servers accept the command line options describedbelow. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
:displaynumber The X server runs as the given displaynumber, which bydefault is 0. If multiple X servers are to run simultaneously on a host, each must have a unique display number. See the DISPLAY NAMES section of the X(7) manual page to learn how to specify which display number clients should try to use.
# 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.
???
Felix Miata wrote:
deloptes composed on 2016-11-30 07:30 (UTC+0100):
Felix Miata wrote:
xserver
In your example I don't see how you are passing the display number to xserver command
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?
I was thinking you want to run xserver on different port/screen
All of the X servers accept the command line options describedbelow. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
:displaynumber The X server runs as the given displaynumber, which bydefault is 0. If multiple X servers are to run simultaneously on a host, each must have a unique display number. See the DISPLAY NAMES section of the X(7) manual page to learn how to specify which display number clients should try to use.
# man X(7) bash: syntax error near unexpected token '('. # man X no manual entry for X
Strange I have man for Xorg and for X - perhaps you are missing something. And I have full featured man page for tdecmshell
# 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.
Qt options: --display <displayname> Use the X-server display 'displayname'
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.
???
What you show on the image means you change the DPI on display :0 (default) and it will impact all programs run there.
I haven't spent too much time with X, but also not too less. AFAIR it was 1.GPU -> 1.Screen -> 1..n Display(s)
In general I do not understand what you want to achieve - you can not run a Xserver from within Xserver and let it bind to the same screen port which is already taken by the first Xserver running. In my opinion you can run xserver on :1 or :2 from the native console (but it would require more work to run applications there ... see session management)
man xserver ... -dpi resolution sets the resolution for all screens, in dots per inch. To be used when the server cannot determine the screen size(s) from the hard‐ ware.
At least AFAIR this is what vnc is doing, where (AFAIR) you specify the port example :5 and then can connect from remote to xserver on :5 remote via vnc.
regards
I hope this helps
deloptes composed on 2016-12-01 01:17 (UTC+0100):
Felix Miata wrote:
deloptes composed on 2016-11-30 07:30 (UTC+0100):
Felix Miata wrote:
xserver
In your example I don't see how you are passing the display number to xserver command
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?
I was thinking you want to run xserver on different port/screen
That I know how to do when it's what I want to do. :-)
All of the X servers accept the command line options describedbelow. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
:displaynumber The X server runs as the given displaynumber, which bydefault is 0. If multiple X servers are to run simultaneously on a host, each must have a unique display number. See the DISPLAY NAMES section of the X(7) manual page to learn how to specify which display number clients should try to use.
# man X(7) bash: syntax error near unexpected token '('. # man X no manual entry for X
Strange I have man for Xorg and for X - perhaps you are missing something.
'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.
And I have full featured man page for tdecmshell
On openSUSE, or on a Debian? (sidetracking....)
# 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.
Qt options: --display <displayname> Use the X-server display 'displayname'
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.
???
What you show on the image means you change the DPI on display :0 (default) and it will impact all programs run there.
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.
I haven't spent too much time with X, but also not too less. AFAIR it was 1.GPU -> 1.Screen -> 1..n Display(s)
In general I do not understand what you want to achieve
Clearly. :-)
- you can not run a
Xserver from within Xserver and let it bind to the same screen port which is already taken by the first Xserver running. In my opinion you can run xserver on :1 or :2 from the native console (but it would require more work to run applications there ... see session management)
man xserver ... -dpi resolution sets the resolution for all screens, in dots per inch. To be used when the server cannot determine the screen size(s) from the hard‐ ware.
At least AFAIR this is what vnc is doing, where (AFAIR) you specify the port example :5 and then can connect from remote to xserver on :5 remote via vnc.
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
Felix Miata wrote:
deloptes composed on 2016-12-01 01:17 (UTC+0100):
Felix Miata wrote:
deloptes composed on 2016-11-30 07:30 (UTC+0100):
Felix Miata wrote:
xserver
In your example I don't see how you are passing the display number to xserver command
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?
I was thinking you want to run xserver on different port/screen
That I know how to do when it's what I want to do. :-)
The thing is we don't know and above this the "why" is not clear :)
All of the X servers accept the command line options describedbelow. Some X servers may have alternative ways of providing the parameters described here, but the values provided via the command line options should override values specified via other mechanisms.
:displaynumber The X server runs as the given displaynumber, which bydefault is 0. If multiple X servers are to run simultaneously on a host, each must have a unique display number. See the DISPLAY NAMES section of the X(7) manual page to learn how to specify which display number clients should try to use.
# man X(7) bash: syntax error near unexpected token '('. # man X no manual entry for X
Strange I have man for Xorg and for X - perhaps you are missing something.
'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.
And I have full featured man page for tdecmshell
On openSUSE, or on a Debian? (sidetracking....)
debian (of course)
# 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.
Qt options: --display <displayname> Use the X-server display 'displayname'
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.
???
What you show on the image means you change the DPI on display :0 (default) and it will impact all programs run there.
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.
Of course you can not change the DPI of already running programs, because they have already got the DPI value when starting.
I haven't spent too much time with X, but also not too less. AFAIR it was 1.GPU -> 1.Screen -> 1..n Display(s)
In general I do not understand what you want to achieve
Clearly. :-)
- you can not run a
Xserver from within Xserver and let it bind to the same screen port which is already taken by the first Xserver running. In my opinion you can run xserver on :1 or :2 from the native console (but it would require more work to run applications there ... see session management)
man xserver ... -dpi resolution sets the resolution for all screens, in dots per inch. To be used when the server cannot determine the screen size(s) from the hard‐ ware.
At least AFAIR this is what vnc is doing, where (AFAIR) you specify the port example :5 and then can connect from remote to xserver on :5 remote via vnc.
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*.
You are misunderstanding the display term (I think). Display is not your monitor. It is a virtual entity.
[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
I will have to look into the links later, but from what I know it is not possible to set DPI per application on the same screen/server. It could be that you can change the font size (what we actually already have), but this is a different story.
regards
PS: and I am not teaching, I am just sharing my knowledge and learning something in the same time.
deloptes composed on 2016-12-01 08:50 (UTC+0100):
Felix Miata wrote:
...from what I know it is not possible to set DPI per application on the same screen/server. It could be that you can change the font size (what we actually already have), but this is a different story.
PS: and I am not teaching, I am just sharing my knowledge and learning something in the same time.
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
Felix Miata wrote:
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:
I would look into the documentation and code. We are not studying something that is outside of our worl like natural science where we observe :) This here is pure mathematics
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.
correct - this is the window manager ( in my case twin)
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)
I am not sure what you mean
"If your image is 72ppi (pixels per inch), then one point will equal exactly one pixel. Point is a physical unit of length, used in typography. It's equal to 1/12 Pica, and 1 Pica = 1/6 inch. So 1 pt = 1/72 inch."
"In applications, a point is exactly 1/72 inches." http://graphicdesign.stackexchange.com/questions/199/point-vs-pixel-what-is-...
c-Server's logical density increase caused text size increase in the new application instance (text sized in "physical" units: pt)
this is true
d-Nothing other than text size seems to have been changed
Have you tested anything else?
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
If you change dpi and restart the window manager I would expect that icons look different. Perhaps you can test that
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
Under look and feel -> fonts you can enforce the DPI
regards
deloptes composed on 2016-12-01 22:08 (UTC+0100):
Felix Miata wrote:
If you change dpi and restart the window manager I would expect that icons look different. Perhaps you can test that
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.
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
Under look and feel -> fonts you can enforce the DPI
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.
Felix Miata wrote:
deloptes composed on 2016-12-01 22:08 (UTC+0100):
Felix Miata wrote:
If you change dpi and restart the window manager I would expect that icons look different. Perhaps you can test that
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.
In the control panel there is option to select the icon size for the theme. I prefer 48px - look there.
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
Under look and feel -> fonts you can enforce the DPI
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.
Anyway - I think what we learned is that DPI must be set when X is starting. The setting does not do anything different.
regards
deloptes composed on 2016-12-02 09:23 (UTC+0100):
Felix Miata wrote:
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.
In the control panel there is option to select the icon size for the theme. I prefer 48px - look there.
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.
Felix Miata wrote:
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
but this is a setting that you make one time. I think you don't understand completely how this works. I'm not sure my understanding is correct, but let me share what I understand. When you have a physical display lets say 21" diagonal. This gives you particular dimensions. Look here https://en.wikipedia.org/wiki/Display_size#Display_sizes_of_common_TVs_and_c...
And this also gives you a specific set of pixels supported. Changing DPI changes how many pixels are involved in displaying whatever you want to display. On LCD display lower resolution is somehow poor, though everything looks bigger. To solve this I choose bigger icons and DPI 120 for the fonts.
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.
What you are talking here sounds nice in theory but in practice it looks quite different. Example: I have a LCD (notebook) with 1366x768 and external monitor 1920x1080. In theory I could "clone" and have the same output on both, only I would see it much smaller on the LCD. However our beloved Intel graphics do not support this. You know there is some hardware part that must do the job in practice. So what I can do is either base on 1366x768 or on 1920x1080. I prefer the latter and do xrandr --output eDP1 --scale-from 1920x1080.
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.
Well it turns out that the subject is invalid as you (1)can not run this as normal use, (2)you can not run it from within an X session and even if you could, (3)you can not use it as you need a window manager, session manager etc etc.
I hope this helps
regards
deloptes composed on 2016-12-02 19:56 (UTC+0100):
When you have a physical display lets say 21" diagonal. This gives you particular dimensions. Look here https://en.wikipedia.org/wiki/Display_size#Display_sizes_of_common_TVs_and_c...
And this also gives you a specific set of pixels supported. Changing DPI changes how many pixels are involved in displaying whatever you want to display.
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
Felix Miata wrote:
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
Thats impressive
deloptes composed on 2016-12-01 22:08 (UTC+0100):
Felix Miata wrote:
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)
I am not sure what you mean
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.
"If your image is 72ppi (pixels per inch), then one point will equal exactly one pixel. Point is a physical unit of length, used in typography. It's equal to 1/12 Pica, and 1 Pica = 1/6 inch. So 1 pt = 1/72 inch."
"In applications, a point is exactly 1/72 inches." http://graphicdesign.stackexchange.com/questions/199/point-vs-pixel-what-is-...
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.
On 2016/11/30 12:29 PM, Felix Miata wrote:
man tdecmshell produces no manual entry. tdecmshell --help-all doesn't seem to show what I'm looking for AFAICT.
What I'd like is to open 'tdemshell xserver', then run an xrandr command to change DPI, finally run 'tdemshell xserver' to compare the before and after impact from the xrandr command. It doesn't work. The second tdecmshell run simply focuses the original window. Is there any way to do what I want? If not, is it a feature that might be added to 14.1 if I filed a feature request bug?
For now what I have to do as workaround is as shown here (using xterm) :-(: http://fm.no-ip.com/SS/dpi108vs133.jpg
No idea what effort that would require, have to see how the software is done. Wouldn't it be easier to open the first tdecmshell xserver, take a snapshot, make the xrandr changes, then open the tdecmshell again and compare? Just as a temporary workaround at least?
Cheers Michele
Michele Calgaro composed on 2016-11-30 18:15 (UTC+0900):
Felix Miata wrote:
man tdecmshell produces no manual entry. tdecmshell --help-all doesn't seem to show what I'm looking for AFAICT.
What I'd like is to open 'tdemshell xserver', then run an xrandr command to change DPI, finally run 'tdemshell xserver' to compare the before and after impact from the xrandr command. It doesn't work. The second tdecmshell run simply focuses the original window. Is there any way to do what I want? If not, is it a feature that might be added to 14.1 if I filed a feature request bug?
For now what I have to do as workaround is as shown here (using xterm) :-( : http://fm.no-ip.com/SS/dpi108vs133.jpg
No idea what effort that would require, have to see how the software is done. Wouldn't it be easier to open the first tdecmshell xserver, take a snapshot, make the xrandr changes, then open the tdecmshell again and compare? Just as a temporary workaround at least?
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.
On Wednesday 30 of November 2016 10:15:42 Michele Calgaro wrote:
On 2016/11/30 12:29 PM, Felix Miata wrote:
man tdecmshell produces no manual entry. tdecmshell --help-all doesn't seem to show what I'm looking for AFAICT.
What I'd like is to open 'tdemshell xserver', then run an xrandr command to change DPI, finally run 'tdemshell xserver' to compare the before and after impact from the xrandr command. It doesn't work. The second tdecmshell run simply focuses the original window. Is there any way to do what I want? If not, is it a feature that might be added to 14.1 if I filed a feature request bug?
For now what I have to do as workaround is as shown here (using xterm) :-(: http://fm.no-ip.com/SS/dpi108vs133.jpg
No idea what effort that would require, have to see how the software is done. Wouldn't it be easier to open the first tdecmshell xserver, take a snapshot, make the xrandr changes, then open the tdecmshell again and compare? Just as a temporary workaround at least?
Cheers Michele
I'm not sure whether is the ability to run two identical tdecmshell good idea. Most modules contain not only information, but mainly the settings. When will be opened two same settings, would be unsynchronized and saving settings could cause unwanted results.
-
deloptes -
Felix Miata -
Michele Calgaro -
Slávek Banko