Overriding individual user preferences

[afalkenhahn]

Currently, TheBar.mcc is using a pretty awkward and non-standard way of enforcing absolute prioritization of user preferences over individual application requirements. For example, setting MUIA_TheBar_ViewMode to MUIV_TheBar_ViewMode_Gfx during object creation doesn't have any effect at all. TheBar simply ignores it and uses the user's preferences instead.

The only way to override this is to set MUIA_TheBar_IgnoreAppearance to TRUE. But this is some kind of master reset because it completely drops all user settings and resets them to default values. Thus, it is currently impossible to change a single user setting to a hardcoded one without going back to factory settings altogether, i.e. it's not possible to enforce an icon-only toolbar without doing a hard reset using MUIA_TheBar_IgnoreAppearance.

I think this needs a more elegant solution because the current one is not very useful.

Here is another example: Say an app wants to use MUIA_TheBar_MouseOver. According to the docs, this only works with either MUIA_TheBar_Raised or MUIA_TheBar_Sunny set to TRUE. However, the latter two are user settings once again and apps cannot override them without doing a master reset using MUIA_TheBar_IgnoreAppearance. So apps can't really use MUIA_TheBar_MouseOver with the user's settings at all because you don't know whether or not the user has SUNNY or RAISED enabled. It's all pretty messed up IMHO and needs some better design.

[tboeckel]

The mess was done by Alfonso Ranieri, not by us. The big problem is to keep compatibility when choosing between user and applications defined settings. I admit that the current situation is not ideal, but it is also hard to extend the current way to handle user/application settings without loosing backward compatibility.

[jens-maus]

Then we should bump the major version at some point and drop backward compatibility. IMHO we should not keep backward compatibility under all circumstances.

[afalkenhahn]

Why not introduce a new tag? When it is set, TheBar behaves in new mode, otherwise in compatibility mode.

[jens-maus]

Oh no, please no such clumsy things. That's exactly what major version numbers are for. If they are bumped compatibility is not guaranteed and applications are supposed to be adapted. Amiga developers and users really have to finally learn what the rest of the world learned over the last twenty years: backward compatibility is not something which should always have the highest priority.

[afalkenhahn]

That's easier said than done. The peculiar situation of Amiga software demands
more flexible solutions. Just take a look at Aminet. There are so many apps around
which aren't maintained anymore and the author just doesn't care anymore. Since
we have lots of old unmaintained software I'm all for keeping compatibility. Of
course it's different in the real world, but Amiga isn't the real world anymore.

[jens-maus]

Well, lets not drop into philosophical discussions, but let me just point out that IMHO you could easily delete 95% of what is in Aminet without anyone actually requiring it. So IMHO instead of always looking back to times where Amiga was still popular the rest of us Amiga developers should better focus on implementing new features instead of making sure that old, bloating and unrequired software still runs and that applications can still be executed on OS 1.3...

But coming back to the TheBar.mcc case here I guess the situation is way different:

1. AFAIK there are only 2-3 applications actually using the TheBar.mcc so the situation is far better. In addition, all these applications are still maintained or open source, so there shouldn't be any problems in forcing developers to update their applications.
2. We are talking about modifying only user interface appearance priorities. So by simply changing the default the only really bad thing that would happen would be that users might have to adapt their user preference settings again which IMHO isn't really so bad that we should introduce a clumsy tag for a case that probably doesn't really harm.

So IMHO we should simply change the appearance preference default and see what actually will happen because IMHO fixing this problem is far more important than taking care that some user defined color or setting of TheBar is always maintained throughout all upcoming versions....

[afalkenhahn]

Sure, go ahead then. I don't have any old software that depends on the old behaviour
anyway :)

[jens-maus]

Ok. So what do you @tboeckel think about that? One of the major questions would be how to actually modify TheBar and which tags should take preference over user modifications? I can't remember, but how is this actually be performed for other classes?