Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#241 closed enhancement (fixed)

Use the new title class in MUI prefs window Frame&Bakckground

Reported by: Javier de las Rivas Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R3
Component: Title.mui Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

Problem

Analysis

Enhancement recommendation

Attachments (1)

sgrab000.png (68.4 KB) - added by Javier de las Rivas 4 years ago.
YAM and 3 tabs, one shows cutted text

Download all attachments as: .zip

Change History (8)

comment:1 Changed 4 years ago by Javier de las Rivas

ops, rewriting enhancement:

Can at least for AOS4 the new title class be used instead of "old" register class?
It shows on window with 'Frame' and 'Background' tabs, you can see/get such window clicking on MUI prefs below 'MSG_CFGL_SHOWMCC' button/object 'Clipboard'

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

What kind of advantage do you expect from such a change?

Internally Register class is using Title class already. For compatibility reasons it just avoids adding scroll buttons in case the tabs don't fit into the window.

Furthermore MUI4 is available for AmigaOS3, too. So why limit anything to AmigaOS4 which is absolutely not depending on the system?

comment:3 Changed 4 years ago by Javier de las Rivas

Just because MUI4 (MUI prefs) has/uses the new title class and if you set 'Stretching to 0%' (GROUPS) on the same MUI prefs you see the tabs OK (just at the width of the tab label) and then you click on an object (in MUI prefs) that uses Frame&Background tabs you only see F&B (the workaround you added for register class + Stretching 0%).

Alas all users using AOS4 uses MUI4, that's why I asked it for AOS4 only.
And yes, a better solution will be check for mui_lib and if MUI4 use title class in MUI prefs.

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

Component: MUI prefs applicationTitle.mui
OS Platform: AmigaOS4All
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

There is no need to switch classes. This has to be resolved at the root.

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

Resolution: fixed
Status: assignedclosed

In 4953:

  • Title.c: reworked the tab dimension calculation to reduce the width only if there is not enough space. The stretching will become effective if the default width of all tab objects leaves enough space. Both the default and the minimum width override the space left after the stretching. This closes #241.

comment:6 Changed 4 years ago by Javier de las Rivas

YES!!! Great job man.

Just a minor glitch. What width takes it by default for all tabs on same group?
'cos If I have 3 tabs with different size lengths it seems it uses the size of first tab as default for all.

See pic attached, the 2nd tab is 'Componer Mensaje', but it's cutted to 'Componer Men'.

Any chance to use per tab width?

Changed 4 years ago by Javier de las Rivas

Attachment: sgrab000.png added

YAM and 3 tabs, one shows cutted text

comment:7 in reply to:  6 Changed 4 years ago by Thore Böckelmann

Replying to javier:

Just a minor glitch. What width takes it by default for all tabs on same group?
'cos If I have 3 tabs with different size lengths it seems it uses the size of first tab as default for all.

See pic attached, the 2nd tab is 'Componer Mensaje', but it's cutted to 'Componer Men'.

I know this effect, but right now I have no idea how to work around it in a consistent fashion. MUI still tries to make all tabs equally wide, even if there is only one very wide tab and all the others are mush more narrow. The wide tab will then get its text truncated, although it would be more intuitive to make the other tabs more narrow while keeping the wide tab at its preferred size as long as possible. I just have to cramp all this into one single formular…

Note: See TracTickets for help on using tickets.