Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#118 closed bug (fixed)

MWB Colours

Reported by: Mikhail Malyshev Owned by: Thore Böckelmann
Priority: normal Milestone: 3.9-2015R1
Component: muimaster.library Version: 3.9-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

After MUI39R3 you have done something to the pallet.
This is not good since it trashes colour schemes.
Please return the default 4 subtle grey/pimk MWB colours.
Otherwise many gadgets get a horrible white colour and not a nice light grey they should have, and there is no way to change it.

Attachments (7)

WB-GOOD.PNG (262.5 KB) - added by Mikhail Malyshev 5 years ago.
WB-BAD.PNG (281.0 KB) - added by Mikhail Malyshev 5 years ago.
sliders.png (50.3 KB) - added by Thore Böckelmann 5 years ago.
Sliders page of MUI prefs
myGUI.prefs (1.7 KB) - added by Mikhail Malyshev 5 years ago.
XEN style button prefs
MUI4.png (38.2 KB) - added by Mikhail Malyshev 5 years ago.
MWB-8Bit.png (32.2 KB) - added by Mikhail Malyshev 5 years ago.
MWB-HiColour.png (85.3 KB) - added by Mikhail Malyshev 5 years ago.

Download all attachments as: .zip

Change History (28)

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

Component: undefinedmuimaster.library
Milestone: MUI 3.9-2014R4
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

The only change regarding colors was the added support for VisualPrefs' internal settings. That has priority over MagicWB colors now. So either adjust your VisualPrefs settings if you are using it, or make sure that ENV(ARC):MagicWB contains the ASCII string "2".

For VisualPrefs the "half shine" and "half shadow" pens should be set to reasonable RGB values. Something between "shadow" and "shine" with "half shine" being a bit brighter than "half shadow".

comment:2 Changed 5 years ago by Mikhail Malyshev

Yes, ENV var is set to 2.0 since 20 years ?
All first 8 pens are locked to WB+MWB colours
VP has the MWB colours set.

Potential problem - half shine pen.
It can not be changed to light grey since it is used for button shine in XEN buttons, and has to be white. I don't see any other way to change that colour.
And the real half shine is actually Foreground pen and is used for the button body (lighter then default grey background).

Sadly VP does not offer any way to change this colour independently,
but does allow to change this attribute for selected and disabled frames independently.

Also in my case this is a simple problem, but with some really cool mods in VP things can go real bad with MUI if it will be connected to this setting.

It should be independent and have it's own setting. Also the first 8 pens can be considered legacy and need to be locked forever for compatibility. The other thing is the new gadgets can/should have their pens configurable, but definitely not by external tools but internally in MUI prefs.

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

Replying to Michael:

Potential problem - half shine pen.
It can not be changed to light grey since it is used for button shine in XEN buttons, and has to be white. I don't see any other way to change that colour.

What does "XEN" mean again here? Does it refer to MUI? To VisualPrefs? To anything else?

These are MUI's pens for the "XEN" frames (frame #6):
normal: MPEN_SHADOW, MPEN_SHINE, MPEN_HALFSHADOW MPEN_BACKGROUND
pressed: MPEN_SHADOW, MPEN_HALFSHADOW MPEN_BACKGROUND

The halfshine pen is not involved at all.

And the real half shine is actually Foreground pen and is used for the button body (lighter then default grey background).

Halfshine and Foreground are different pens in VisualPrefs and only Foreground is used for filling buttons.

comment:4 Changed 5 years ago by Mikhail Malyshev

XEN - 3d style in MWB colours (original example prefs in older mui with XEN's settings)

"Halfshine and Foreground are different pens in VisualPrefs and only Foreground is used for filling buttons."

Correct, Foreground is used for the button, and in XEN style it's halfshine MWB colour. And VP Halfshine is used for top left corner hilight of the XEN styled button, and it is white.

PS: I will try to prepare some screenshots a bit later

Changed 5 years ago by Mikhail Malyshev

Attachment: WB-GOOD.PNG added

Changed 5 years ago by Mikhail Malyshev

Attachment: WB-BAD.PNG added

comment:5 Changed 5 years ago by Mikhail Malyshev

https://muidev.de/raw-attachment/ticket/118/WB-GOOD.PNG

https://muidev.de/raw-attachment/ticket/118/WB-BAD.PNG

The good and the bad colour selection.
In top image we see MUI halfshine pen set correctly.
In bottom image this is no longer obvious.

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

If you don't want to change your VisualPrefs settings, then just change the button background color/image. But this won't help for the arrow images, because these will still be remapped with two equal pens which should be different.

comment:7 Changed 5 years ago by Mikhail Malyshev

That's exactly the problem, I am happy to change it if it worked one way or the other, but in the current situation it's a dead end. Either VP needs to be updated and the halfshine pen made independent or MUI must not assume the colours that VP sets. Since the pen names do not refer to the original MWB/XEN idea.
My VP config is fairly basic and common amongst many other peoples. I can send you the prefs for experiments if needed.

In MUI it is possible to set the button colour to something different then halfshine, but no way to do it for the sliders. Also I don't get it, why you link to VP, the custom pallet needs to be defined in MUI itself.
What colours are currently linked to what in VP?
Or you have experimented with Halfshine and halfshadow only?

comment:8 Changed 5 years ago by Mikhail Malyshev

And I have noticed, in the current state we have lost the pink MWB colour completely.

Changed 5 years ago by Thore Böckelmann

Attachment: sliders.png added

Sliders page of MUI prefs

comment:9 in reply to:  7 Changed 5 years ago by Thore Böckelmann

Replying to Michael:

That's exactly the problem, I am happy to change it if it worked one way or the other, but in the current situation it's a dead end. Either VP needs to be updated and the halfshine pen made independent or MUI must not assume the colours that VP sets. Since the pen names do not refer to the original MWB/XEN idea.

MagicWB expects certain colors at fixed pen numbers to avoid having to remap images to the same palette with different pen numbers. But the system can assign arbitrary pen numbers to its standard pens. And this is what MUI and every other application is using. Look up "struct DrawInfo" in an SDK of your choice and understand its meaning.

If you want VP to be updated then you need to contact Massimo Tantignone. But I am sure he will tell you exactly the same: shine and halfshine pens should have different colors.

My VP config is fairly basic and common amongst many other peoples. I can send you the prefs for experiments if needed.

Feel free to do that.

In MUI it is possible to set the button colour to something different then halfshine, but no way to do it for the sliders.

Wrong. See attached screenshot. You can definitely set the slider knob background to what ever you like.

Also I don't get it, why you link to VP, the custom pallet needs to be defined in MUI itself.

You asked for VP support for the title bar buttons. VP offers the same range of standard pens as AmigaOS4 does that's why it is used now. The palette is in no way "custom". MUI just uses standard pens like SHINEPEN, HALFSHINEPEN or FILLPEN. It is the task of the system preferences to assign the desired colors.

What colours are currently linked to what in VP?

Start GUI prefs of VisualPrefs and see yourself. It is just an extension to what AmigaOS3 already offers.

Or you have experimented with Halfshine and halfshadow only?

MUI takes HALFSHINEPEN, HALFSHADOWPEN, SELECTPEN and SELECTTEXTPEN from VisualPrefs as these are not provided by standard AmigaOS3.

Face it, the HALFSHINE pen is to be set to a color which is not as bright as the SHINE pen, but brighter than the HALFSHADOW and SHADOW pens. Otherwise the name and its usage doesn't make any sense. Why should AmigaOS provide two pens with equal colors but different meanings?

And I have noticed, in the current state we have lost the pink MWB colour completely.

It is not MUI's task to provide this color! If you want to use MagicWB you must use other tools to ensure that certain colors are available. What do you do if you don't run any MUI application? Where do you get the desired colors from in that case? MUI is not responsible to provide the typical MagicWB colors. MUI can only use them. There is no connection or dependence between MUI and MagicWB. MUI does make use of the MagicWB palette in case VisualPrefs is NOT running to override it. But again, MUI assumes that someone else already has set the correct colors to specific pens. If that is not the case then MUI will do nothing against that.

Changed 5 years ago by Mikhail Malyshev

Attachment: myGUI.prefs added

XEN style button prefs

comment:10 Changed 5 years ago by Mikhail Malyshev

Added example GUI prefs file with XEN style settings.

Sorry, not slider → scrollbar color is not selectable

VP, yes, to fix the window gadgets that got broken for some reason.
But not to brake the colour systems :-(

I know, the naming of pens was introduced, and in ideal world it should be as you say, but for some reason this has never been done properly for OS3 and it got linked to everything in OS4 integration, since all the GUI element were redesigned. Played a bit with OS4 GUI settings and got really disappointed, it's no longer possible to have a black frame around a pressed button ;-(
Or it's not that trivial to setup.

Was not MUI and MWB a symbiosis thing ?
Every good amiga owner has the MWB pens locked, usually by FullPalette, that in turn is in a way part of VP, and in OS4 it was integrated in to an AllInOne thing.

So the answer is simple, yes, we have the colours we need, but now they are not used since VP is put in preference when it should not. Since on OS3 it is intended for intuition/gadtools and partially classacts/reaction gui setting.

And why GUI settings for one GUI system should effect the GUI of another GUI system ? This only limits configurability.

Another example of problematic setup is AmiKit, that will fail since it's GUI setting mostly 4 colours, so white/blacks and halfs/shadow are same colours.

So if you really wish to keep this, then please please please, add another item to the tweaks page or env vars as a temporary solution.

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI4.png added

comment:11 Changed 5 years ago by Mikhail Malyshev

https://muidev.de/attachment/ticket/118/MUI4.png
This MUI4 (AmiKit version) demonstrates a very good example of how pallet management fails with the current linking to system/VP pens under 3.x.
This is the default AmigaOS3 preset! And mostly of interest is the jumping text colour for different places, it's impossible, why are the same things differently coloured?! And we get grey on grey everywhere.

PS: And I have explicitly setup VP to proper colours in current MUI thinking for this test, otherwise all bitmap images and other things go white and funny colours ets (you know the story already)

Last edited 5 years ago by Mikhail Malyshev (previous) (diff)

comment:12 Changed 5 years ago by Mikhail Malyshev

Cloud bubble help gets white text on white background.
Popup menues when mouse moves over items and back change colours unpredictably.

And how will we be able to separate settings for different apps if some of the gui settings will be linked to the other prefs (OS or VP defined colours)?

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

Replying to Michael:

Cloud bubble help gets white text on white background.
Popup menues when mouse moves over items and back change colours unpredictably.

And how will we be able to separate settings for different apps if some of the gui settings will be linked to the other prefs (OS or VP defined colours)?

You are guessing wrong again. The bubble help is using pens only which exist on every system. I suppose you don't have AfAOS running in which case graphics/SetRPAttrs() doesn't handle RGB values instead of pens. Without that feature the current pen will remain unchanged at whatever value it was before and hence may print text in undesired colors.

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

In 4272:

  • mastergfx.c: use SetRPAttrs() to set direct RGB pens only if that function is really found to be able to handle RGB pens. This fixes the random colors on AmigaOS3 systems with CyberGraphics but without AfAOS. This as refs #118.

comment:15 Changed 5 years ago by ancalimon

I have the same problem with white text on white help bubbles or unreadable text on some places because of grey on grey and white on white.

I'm not using afaos because it's not stable on my system (CStormPPC + CVisionPPC). Using AfAOS fixes this problem.

I'm having difficulties setting up VisualPrefs and FullPalette.

comment:16 Changed 5 years ago by Mikhail Malyshev

Interesting, played a bit with AfA and MUI4. And this has an interesting effect similar to MUI3.9 and MWB colours possibly related.

When AfA is running MUI4 selects the correct greys for buttons and (nitmap) images. But when we do it slightly differently eg. FourOne images become coloured with white background. Is it also somewhat related?
Also it's puzzling why some images are effected while other are not. And why all images are effected under 3.9 (get white instead of grey), bitmaps are either dependent on pallet or not, but in our case it's neither of the two since the correct colours are available but not used (an how can halfshine VP pen effect bitmaps?).

These are just thoughts that might raise a few ideas… Still waiting for a satisfactory solution…

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

In 4299:

  • Imagespace.c: brush images (*.mf0/1, *.mb0/1, *.mbr) are now converted to ARGB data using the palette from the individual image files if they are use on truecolor screens. This makes it possible to always display them with the correct colors no matter what palette is set on the destination screen. This refs #118.

Changed 5 years ago by Mikhail Malyshev

Attachment: MWB-8Bit.png added

Changed 5 years ago by Mikhail Malyshev

Attachment: MWB-HiColour.png added

comment:18 Changed 5 years ago by Mikhail Malyshev

https://muidev.de/attachment/ticket/118/MWB-8Bit.png

Set the light grey for buttons as a custom colour (original mui had a pen selection)s so had to redefine the old prefs.

The fix has partial effect in HiColour and nothing for 8bit or less screens.
Why are the MWB styled images remapped so weirdly while others are ok?
The MWB pens are always available, and there are free pens too if it was required.
It looks like current MUI just insists on replacing the MWB light grey with VP halfshine, it should not do so, and should not do so for other colours too since it raises all sort of problems and prevents two mui apps from having completely independent palette settings since some setting are fixed by third party settings.

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

Resolution: fixed
Status: assignedclosed

In 4310:

  • mastergfx.c, Settings.c, misc: implemented a new settings item to control the usage of VisualPrefs to supply enhanced system pen settings. This setting is available for AmigaOS3 only. This closes #118.

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

Milestone: MUI 3.9-2014R4MUI 3.9-2015R1

Milestone renamed

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

Milestone: MUI 3.9-2015R13.9-2015R1

Milestone renamed

Note: See TracTickets for help on using tickets.