Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#188 closed enhancement (fixed)

Small layout change for some prefs

Reported by: Mikhail Malyshev Owned by:
Priority: normal Milestone: 4.0-2015R2
Component: MUI prefs application Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

Please do some layout changes to the following MUI/Prefs windows,
so that the final window width is smaller.

  1. MUI/Prefs/Windows

In English it is fairly ok, but for translated versions the window gets really wide.

Solution: make options in a vertical list (currently it's three columns) that add up to final width

  1. MUI/Prefs/Adjust Frames & Backgrounds window

Also needs some layout adjustment to make it around 20 pixels less wide (tried it with different languages and micro fonts) and the min window is currently limited to about 660 pixels, just a bit too wide.

The rest of main mui prefs seem to be ok.

This will make the main MUI prefs work better for basic OS3/OS4 setup under AGA with default 640x screen or when the prefs are called on a small application screen.

Attachments (2)

MUI4-frames.png (142.8 KB) - added by Mikhail Malyshev 5 years ago.
mui-prefs-window.png (203.0 KB) - added by Mikhail Malyshev 4 years ago.

Download all attachments as: .zip

Change History (16)

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI4-frames.png added

comment:1 Changed 5 years ago by Mikhail Malyshev

https://muidev.de/attachment/ticket/188/MUI4-frames.png

Idea of small layout change for the frames, this should make the window small enough to fit 640 wide screens.

Also you can spot that original rounded frame (3rd from right) used double pixels.
It would be good to restore the original frames there, and add the newer single pixel rounded frame to the set of newer frames below.

This will make newer MUI more compatible to old style prefs.

comment:2 Changed 4 years ago by Mikhail Malyshev

Any chance to see an update here before release date?

comment:3 in reply to:  2 Changed 4 years ago by Thore Böckelmann

Replying to Michael:

Any chance to see an update here before release date?

Short answer: no

Long answer: no, because the size limitation is no solely related to the frame selection, but to the image selection, too. The file browser (although invisible in certain situations) is quite wide and therefore is responsible for the minimum width of the window.

comment:4 Changed 4 years ago by Mikhail Malyshev

You have made it look so complicated ;-)
Should not be difficult to move the newer frames (added after 3.8)
to a new row, this will make enough space (we only need to find 20 pixels!)
and the image browser can have a 20 pxl less default size if it has any limits
we can't see it from the users side, and when there is no extra images
the limit is definitely the built in frames list in a single row

MUI/Prefs/Windows - this has nothing to do with file browser

comment:5 Changed 4 years ago by Thore Böckelmann

In 4705:

  • Frameadjust.c: splitted the internal frame display into two double lines instead of just one double line. This refs #188.

comment:6 Changed 4 years ago by Thore Böckelmann

In 4706:

  • Backgroundadjust.c: move all objects to manipulate an external bitmap image below the file selector to allow a more narrow window. This refs #188.

comment:7 Changed 4 years ago by Thore Böckelmann

Milestone: 4.0-2015R2
Priority: undecidednormal
Resolution: fixed
Status: newclosed

The last two changes are everything I can do. You very obviously have no clue what is really causing the size requirements. Just changing the layout of the frame selection is not enough. Althout splitting the internal frames into two lines will make the window smaller this only affects the windows for selecting a frame only.

As soon as a frame and and background is to be configured (and this happens really often in MUI prefs) the background selection page dominates the window dimensions more than the frame selection page. This happens, because there are some sliders and checkmarks on the right side of the file selector (in case a custom bitmap image is used) which make the window a bit too wide. I moved these objects below the file selector to save some pixels. But it turned out that now the window becomes higher than 480 pixels. The original maximum window sizes of 640x256 defined by Stefan Stuntz some decades ago are simply FAR too limited for today's GUIs. That's why I'd propose 800x600 as minimum screen size. Face it, classic machines with 640x512 screens at most are a dying species, either because or their age or because of their limited capabilities.

This is my final statement on this topic and I don't want to hear any further complaints. You got what you asked for, now accept the results and be happy with them.

Changed 4 years ago by Mikhail Malyshev

Attachment: mui-prefs-window.png added

comment:8 Changed 4 years ago by Mikhail Malyshev

Excellent job, just missed one issue with windows settings
In english it is fairly compact, but in other languages I fear it can have many problems and it would be good to move one block like as shown (or do other arrangements) the window has no hight limit since it has a virtual scroll bar
https://muidev.de/attachment/ticket/188/mui-prefs-window.png

Window text font colour gadget can also be moved below the Fixed width font setting thus making the window much slimmer and tidier.

As for the setting with file selector (in case a custom bitmap image is used)
it fits nicely 640x400 screen here in english (need to shorten russian colour names on my side for it to work perfectly) and imho it's not a perfect solution (as 640x256 defined by Stefan Stuntz) but acceptable as a NEW bare minimum since it is still compatible with the default screen of OS4 for classic or many programs/games that use minimalistic square pixel VGA type screens.

Otherwise many thank for understanding and making those small but important changes that make life a little bit easier and fun.

comment:9 Changed 4 years ago by Mikhail Malyshev

Resolution: fixed
Status: closedreopened

comment:10 Changed 4 years ago by Thore Böckelmann

Resolution: fixed
Status: reopenedclosed

Insert line breaks!

Honestly, no matter how I change the layout there will always be a translations in a certain language which causes the window dimensions to exceed the archaric limit of 640x256 (or even 640x512). Stefan Stuntz definitely did not take this fact into account back when he defined the restrictions. But this is the price one has to pay for full locale support. So either shorten your translated strings or insert line breaks.

It is simply not possible to change the window layout in such a way that arbitrary translated strings (which an application has no control over) will never violate the archaic 640x512 limit.

comment:11 Changed 4 years ago by Mikhail Malyshev

Line breaks, yes, I know! But it looks crap in these case. And this case is a bit special since it effects almost every language if you try to make the text explain what it is and short single words simply do not work here.

There is plenty of space for vertical layout (scroll bar in window border)
so the V-limit is not such a big problem here, only H-limit.

It will also look better if the text colour gadget is placed below and in line with the font selection gadgets.

PS: I always try to make the best possible translation and check for layout problems and only is cases when it is absolutely impossible to find a reasonable solution we go the crop word method, and in this case imho it's not necessary.

And I am not asking for automatic re-layout, just give it a little bit more thought before cramming everything together. A list of options sorted vertically will look good and work for almost every language but really some exotic ones for which nothing standard would work anyway.

comment:12 Changed 4 years ago by Mikhail Malyshev

Done some castration in the Russian translation, hopefully the window will fit.
Will see it in the next nightly update, but it will be very tight.

And I have to admit that I have checked several languages, and all have big problems with this window growing much bigger then it can/should be.

I would recommend you to have a look on the German version of prefs/windows
and fine tune the translation of the NlistViews mcp that just pops out of 640 size in common (almost default XEN setting) on lower end systems XHelevetica 11 font.

Other mcp pref windows seem to be safe.

comment:13 in reply to:  12 Changed 4 years ago by Thore Böckelmann

Replying to Michael:

And I have to admit that I have checked several languages, and all have big problems with this window growing much bigger then it can/should be.

I would recommend you to have a look on the German version of prefs/windows
and fine tune the translation of the NlistViews mcp that just pops out of 640 size in common (almost default XEN setting) on lower end systems XHelevetica 11 font.

You still fail to understand what Stefan Stuntz wrote back in 1997 (release of MUI 3.8). His version of MUIdev.guide only states that each window of an application should (read again: "should", not "must") fit on a 640x256 screen while using the topaz/8 font. Nothing more, nothing less. He didn't mention any specific theme or whatsoever. Therefore one has to assume the unmodified builtin settings, except the font. How about that?

And even if the current layout still causes a slightly too large window then I still no not really care. Things have changed since then. Nobody uses 640x256 screens anymore, and even if someone nevertheless still does, then MUI4 is not the appropriate GUI system for these people. MUI4 is targeted at powerful systems, not at basic systems. Therefore I don't care if a window does not fit on a 640x256 screens, because this is no screenmode of a powerful system.

comment:14 Changed 4 years ago by Mikhail Malyshev

640x400(480) is usually the basic screen mode for VGA cards.
And yes, I totally agree that topaz/8 and 640x256 limits are no longer valid.

Note: See TracTickets for help on using tickets.