So... new install of 12.2 on Lenovo ThinkPad T530, 1600x900 resolution, selected XFCE as default WM.
When I open up any YaST module , it always comes up in a fairly small box on the screen (maybe 4" w x 3"h) regardless of how it is configured when I close it out. I then have to drag/expand it to a usable size, and click/drag all the frames between window areas to get them to where I can actually read/use the menus and lists contained within.
Any ideas on why this is happening, and on how to fix it?
TIA,
Monte
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2012-12-08 at 12:11 -0800, Monte Milanuk wrote:
So... new install of 12.2 on Lenovo ThinkPad T530, 1600x900 resolution, selected XFCE as default WM.
When I open up any YaST module , it always comes up in a fairly small box on the screen (maybe 4" w x 3"h) regardless of how it is configured when I close it out. I then have to drag/expand it to a usable size, and click/drag all the frames between window areas to get them to where I can actually read/use the menus and lists contained within.
Any ideas on why this is happening, and on how to fix it?
I have seen other similar reports. No idea of a solution.
- -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar)
On 2012-12-08 12:11 (GMT-0800) Monte Milanuk composed:
So... new install of 12.2 on Lenovo ThinkPad T530, 1600x900 resolution, selected XFCE as default WM.
That's a 15.6" screen, which has a display density of 118 PPI (aka DPI). At 120 DPI, window content is forced to fit into an area designed for a 96 DPI display. The area is a sqrt function, so the available space is 96^2 / 118^2 = 66% of what it was designed for. If you had a 144 DPI screen, it would only be 44.4%. At 192 DPI, it's only 25%.
When I open up any YaST module , it always comes up in a fairly small box on the screen (maybe 4" w x 3"h) regardless of how it is configured when I close it out. I then have to drag/expand it to a usable size, and click/drag all the frames between window areas to get them to where I can actually read/use the menus and lists contained within.
Any ideas on why this is happening, and on how to fix it?
Your description probably fits a bug I just filed since you posted: https://bugzilla.novell.com/show_bug.cgi?id=793565 .
Felix Miata wrote:
That's a 15.6" screen, which has a display density of 118 PPI (aka DPI). At 120 DPI, window content is forced to fit into an area designed for a 96 DPI display.
Applications should be using units like mm or points, not hardware-dependent units like dots or pixels !!!!! The toolkits are supposed to take care of that, so if I say in my preferences that I want system text in 11-point, that is what I get. Ditto, window sizes.
On 2012-12-10 12:37 (GMT) Dave Howorth composed:
Felix Miata wrote:
That's a 15.6" screen, which has a display density of 118 PPI (aka DPI). At 120 DPI, window content is forced to fit into an area designed for a 96 DPI display.
Applications should be using units like mm or points,
Sorta. What they should be using is an em determined from user preferences/settings, a "this" size without regard to how many mm or pt it measures.
not hardware-dependent units like dots or pixels !!!!! The toolkits are supposed to take care of that, so if I say in my preferences that I want system text in 11-point, that is what I get. Ditto, window sizes.
Key phrase: "supposed to"
I'm guessing the toolkits permit or even induce naive construction, like web site styling tools do. :-(
Felix Miata wrote:
On 2012-12-10 12:37 (GMT) Dave Howorth composed:
Applications should be using units like mm or points,
Sorta. What they should be using is an em determined from user preferences/settings, a "this" size without regard to how many mm or pt it measures.
Well an em doesn't make any sense without a point size! With a 16 point font an em is just 16 points, with 8 point font it is 8 points.
Using ems makes sense for the window size of an application like a terminal - I want it 80 ems wide and 24 ems high, perhaps (though why would I use ems for the vertical measurement?).
But it doesn't make sense for a browser, where there are many different font sizes and where I don't want the window to change size if I change my font size preference. I want the text to reflow instead.
Cheers, Dave
Dave Howorth [11.12.2012 13:09]:
Felix Miata wrote:
On 2012-12-10 12:37 (GMT) Dave Howorth composed:
Applications should be using units like mm or points,
Sorta. What they should be using is an em determined from user preferences/settings, a "this" size without regard to how many mm or pt it measures.
Well an em doesn't make any sense without a point size! With a 16 point font an em is just 16 points, with 8 point font it is 8 points.
Yes, correct. The user chooses the font size (for the desktop), and the window opens up x em wide and y em high. The measurement relates to the chosen desktop font.
Using ems makes sense for the window size of an application like a terminal - I want it 80 ems wide and 24 ems high, perhaps (though why would I use ems for the vertical measurement?).
The terminal size should relate to the terminal font size. I usually have a fixed-width font inside a terminal window, and a non-monospaced font outside.
And why measuring the height in em? Maybe because (following http://en.wikipedia.org/wiki/Em_%28typography%29) "One em in a 16 point typeface is 16 points.", and is not nailed to "16 points in width".
But it doesn't make sense for a browser, where there are many different font sizes and where I don't want the window to change size if I change my font size preference. I want the text to reflow instead.
There is no request to adapt the windows size when a font is changed. The discussion was about the size of the window when it opens up.
And: the question was not that a window should always open in the size given by the programmer, but should open with its last size when it is reopened.
Just my 2¢ Werner
On 2012-12-11 12:09 (GMT) Dave Howorth composed:
Felix Miata wrote:
On 2012-12-10 12:37 (GMT) Dave Howorth composed:
Applications should be using units like mm or points,
Sorta. What they should be using is an em determined from user preferences/settings, a "this" size without regard to how many mm or pt it measures.
Well an em doesn't make any sense without a point size! With a 16 point font an em is just 16 points, with 8 point font it is 8 points.
An ordinary user cares not the number of units or the name of the units, so exposing the "pt" size in the UI is not prerequisite to his selection of his choice of "this" size. Under the covers of the app certainly there is some resulting size hopefully measured in pt instead of px. Only the renderer should be concerned with pixels if then; maybe px are exclusively the graphics driver's job, or at least, should be unavailable at the app level.
why would I use ems for the vertical measurement?.
Consistency? Measuring using different units in vertical and horizontal directions is illogical.
But it doesn't make sense for a browser, where there are many different font sizes and where I don't want the window to change size if I change my font size preference. I want the text to reflow instead.
+1 Werner's answer.
On Sat, Dec 8, 2012 at 7:37 PM, Felix Miata mrmazda@earthlink.net wrote:
Any ideas on why this is happening, and on how to fix it?
Your description probably fits a bug I just filed since you posted: https://bugzilla.novell.com/show_bug.cgi?id=793565 . --
Hello Felix,
It sounds like it, but from looking at the screenshots you attached to the bug report, I'd say what I'm seeing is much worse (less usable). I'll see if I can get some screenshots for you (in the middle of going 'round in circles setting up multi-boot on this laptop). Can I attach them to the bug report, or do I need to forward them to you?
Thanks,
Monte
On 2012-12-10 06:57 (GMT-0800) Monte Milanuk composed:
Felix Miata wrote:
Your description probably fits a bug I just filed since you posted: https://bugzilla.novell.com/show_bug.cgi?id=793565 .
It sounds like it, but from looking at the screenshots you attached to the bug report, I'd say what I'm seeing is much worse (less usable). I'll see if I can get some screenshots for you (in the middle of going 'round in circles setting up multi-boot on this laptop). Can I attach them to the bug report, or do I need to forward them to you?
I haven't had XFCE installed anywhere in several years. There may be something different about its behavior, which would make a bug report the right place, maybe a separate one. The one I filed only includes screenshots from QT-based YaST2. Maybe XFCE YaST2 uses GTK or another toolkit?
Regardless, sending to me would always be the wrong place. Screenshots, same as other binary images, should always be uploaded somewhere and links thereto provided, never emailed except by explicit request.
...which is why I asked ;) I didn't know if it would be better to create a separate bug report or to add to the existing one.
If I can get a screenshot I'll post a link and see where things stand from there.
On Mon, Dec 10, 2012 at 9:03 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2012-12-10 06:57 (GMT-0800) Monte Milanuk composed:
Felix Miata wrote:
Your description probably fits a bug I just filed since you posted: https://bugzilla.novell.com/show_bug.cgi?id=793565 .
It sounds like it, but from looking at the screenshots you attached to the bug report, I'd say what I'm seeing is much worse (less usable). I'll see if I can get some screenshots for you (in the middle of going 'round in circles setting up multi-boot on this laptop). Can I attach them to the bug report, or do I need to forward them to you?
I haven't had XFCE installed anywhere in several years. There may be something different about its behavior, which would make a bug report the right place, maybe a separate one. The one I filed only includes screenshots from QT-based YaST2. Maybe XFCE YaST2 uses GTK or another toolkit?
Regardless, sending to me would always be the wrong place. Screenshots, same as other binary images, should always be uploaded somewhere and links thereto provided, never emailed except by explicit request.
-- "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/
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Monte Milanuk <memilanuk@...> writes:
...which is why I asked ;) I didn't know if it would be better to create a separate bug report or to add to the existing one.
If I can get a screenshot I'll post a link and see where things stand from there.
Here is a link to a screen shot of what the YaST Software Manager looks like when opened in XFCE on a 1600x900 15.6" screen...
https://www.dropbox.com/s/5uiu09gpac8f0xm/YaST-screenshot.png?
It looks like that every time I open an app from YaST in XFCE, regardless of how I resize it.
On 2012-12-14 23:47 (GMT) Monte Milanuk composed:
Monte Milanuk writes:
...which is why I asked ;) I didn't know if it would be better to create a separate bug report or to add to the existing one.
If I can get a screenshot I'll post a link and see where things stand from there.
Here is a link to a screen shot of what the YaST Software Manager looks like when opened in XFCE on a 1600x900 15.6" screen...
https://www.dropbox.com/s/5uiu09gpac8f0xm/YaST-screenshot.png?
It looks like that every time I open an app from YaST in XFCE, regardless of how I resize it.
What do you get from output of 'xrdb -query | grep dpi'? What do you get from output of 'xdpyinfo | grep resolution'? What DPI is reported on http://fm.no-ip.com/Auth/dpi-screen-window.html in a Gecko browser?
That image makes me think you have more than one problem, and the YaST Software window may be at least partially a side effect of a bigger problem. That image looks like it was taken of a full desktop, but it's a 1024x576 pixel (still 16:9, same as 1600x900) image. It may be that XFCE/Xorg and YaST are somehow out of sync on screen resolution. The systemsettings window seems appropriate for its surroundings, but the YaST Software window obviously is as you say, insanely small.
Has your $HOME been used with Gnome3 or a late version of Gnome2? If so, there may be a carryover zoom or DPI setting from it that needs to be undone. We first need to know which toolkit YS in XFCE is using, unless you want to just remove all *gtk* from $HOME. QT isn't affected by Gnome settings, while GTK is.
If none of the above gets you anywhere, I'd go ahead and file a bug about the YS window, but then focus on getting 1600x900 with an appropriate DPI setting (117.7 for accuracy, but 120 for better fonts behavior, or 144 if you'd like still bigger fonts and other objects) to bring fonts back into line with higher screen density.
If you're running 1024x576 on purpose (as many people do[1]), there may be more compensation required, and/or less that can be done.
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd464659%28v=vs.85%2...
On Saturday, December 08, 2012 12:11:46 PM Monte Milanuk wrote:
So... new install of 12.2 on Lenovo ThinkPad T530, 1600x900 resolution, selected XFCE as default WM.
When I open up any YaST module , it always comes up in a fairly small box on the screen (maybe 4" w x 3"h) regardless of how it is configured when I close it out. I then have to drag/expand it to a usable size, and click/drag all the frames between window areas to get them to where I can actually read/use the menus and lists contained within.
Any ideas on why this is happening, and on how to fix it?
TIA,
Monte
Did you try to redimension the window by right click the upper side->window redimension-> moving edges to your favorite position and size.
It works for me on Toshiba Netbook.
Hope it help you too.
Regards,
-
Carlos E. R. -
Dave Howorth -
Felix Miata -
Monte Milanuk -
Ricardo Chung -
Werner Flamme