Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#61 closed enhancement (wontfix)

MUI Legacy software support

Reported by: Mikhail Malyshev Owned by:
Priority: normal Milestone: 3.9-2014R2
Component: muimaster.library Version: 3.9-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Since there is plenty of software out there that opens their own public/custom screens, and in many cases this screens are limited to 8-bit depth, please consider improving (or better said restoring/offering a simpler colour requester).
The current fancy widget does not work for this situations.
If needed we can have a small petition for this, I think there will be many people interested, and it does not require much work or reinvention since the code was there before and worked fine.

Change History (4)

comment:1 in reply to:  description Changed 5 years ago by Jens Maus

Replying to Michael:

If needed we can have a small petition for this, I think there will be many people interested, and it does not require much work or reinvention since the code was there before and worked fine.

No reason for a petition. This is no democracy here. Upon reasonable arguments we will decide if we will do something or not as we know best what is good for the future of MUI and what not. As Thore already pointed out, the future belongs to true color displays and anyone not being able or don't want to use true color screens is free to stay with MUI 3.8.

So please bring us technical arguments rather than suggesting a petition. Which software are you talking about and why is this software not able to open true color screens at all or why is this software not being redesigned to do so.

comment:2 Changed 5 years ago by Mikhail Malyshev

There are many cases like that, even a simple popup window from say a messenger client that pops on a non true colour screen of a foreign application and the user decides to configure it's look, he will be in a silly situations because things start to brake and there is no big deal in actually supporting this condition.
For the true colour world it's not required, but you never know what might be the situation, and the GUI layout engine should fall back to a reasonable state and should not be the problem that cause an application to fail.
As far as I know all popular GUI systems work fine in below 15 bit modes, we do not need to invent anything, it was done before and worked for everyone.
Unless you plan to develop and limit MUI to 24bit+ GUI and redesign the hole colour handling system to RGB colour (no pens mode) there is no reason to not support it. (it's only a simple if condition, if screen is less then 8bits, use a simple requester from the old code base)

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

Component: undefinedmuimaster.library
Milestone: MUI 3.9-2014R2
Priority: undecidednormal
Resolution: wontfix
Status: newclosed

That argument is invalid. You can configure anything on any screen, but certain stuff may not appear as expected due to the limited abilities of a colormapped screen. Although a colormapped screen for example cannot display a gradient like a truecolor screen you can neverthess configure the two colors of a gradient and it will look as expected on a truecolor screen.

The same situation arises if the original configuration was done on a truecolor screen and an application is forced to a colormapped screen. Everything will be downgraded to what the current screen offers. The important point is that nothing is lost due to the colormapped screen, just the look is different. But internally everything is preserved.

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

Milestone: MUI 3.9-2014R23.9-2014R2

Milestone renamed

Note: See TracTickets for help on using tickets.