In D2079#86618, @JoshuaJB wrote:

Why put this behind a hotkey?

What's about Ubuntu 14.04? We still have such audience (judging by feedback statistics).

Fixes @elexis's notes from IRC (2019-07-03#0ad-dev):

Reviewed on IRC (from few days).

Did someone test it with an old platform?

Why you didn't change implementation too?

What's the minimal wxWidgets version that supports wxListView?

needs some investigation.

Have you some results? Did you reproduce Stan's issue?

Adds CCamera::Quad.

So, I think we may have only a workaround solution here. Because we have 2 independent libraries each of them thinks that it process all events alone and calls OS API directly.

In D2020#84220, @wraitii wrote:

Suggestion: wouldn't it be better to rename "Get[Near/Far]Plane" to "Get[Near/Far]PlaneDistance"

I don't mind, only note that the distance in the camera space.

Fixes styles.

Renames to autostart-disable-replay by @elexis suggestion.

Also there are occurrences in rP14865 and rP15153.

In D1396#83410, @Angen wrote:

as we are now compiling game with vs15, this is not needed

I tested the patch, it works well. I checked the linked commit and made a search over our repo, and it seems that the patch covers all missed color updates.

In D1994#84008, @Angen wrote:

@vladislavbelov no steps to reproduce needed it is look and see situation

I figured out. It's not used at all. It was added in rP12343, and its usage was removed in rP13687.

In D2013#83996, @wraitii wrote:

I don't think we have a use for it right now, no. So it could be seen as being too much future-proofing.

Renames SetPerspective to SetPerspectiveProjection.

In D2013#83959, @wraitii wrote:

Indeed, which is why I would lock this behind a global mutex, so it goes

1. locale=default
2. T1::ScopedLocale::ctor(L1), locale=L1
3. T2::ScopedLocale::ctor(L2) - blocked
4. T1::ScopedLocale::dtor(), locale=default
5. resuming of T2::ScopedLocale::ctor(L2) - locale=L2
6. T2::ScopedLocale::dtor(), locale=default

Yeah. By the way where it can be useful? Do we have such cases?

In D2013#83948, @wraitii wrote:

Agreed, I think we should also protect these calls behind a global mutex, so that it actually becomes threadsafe.

If you'd use the current implementation of ScopedLocale in multiple threads, then it highly likely wouldn't work. For ex (T1 - thread N1, T2 - thread N2, L1 - locale N1, L2 - locale N2):

I think the following helper could be helpful, at least it may prevent such bugs in reusing:

class ScopedLocale
{
public:
    ScopedLocale(int category, char* newLocale)
        : m_Category(category), m_OldLocale(setlocale(category, NULL))
    {
        TS_ASSERT(setlocale(m_Category, newLocale) != nullptr);
    }
    ~ScopedLocale()
    {
        setlocale(m_Category, m_OldLocale);
    }
private:
    int m_Category;
    char* m_OldLocale;
};

Could you attach steps to reproduce the bug?

In D1492#83849, @smiley wrote:

(most of those posts were removed)

I'm not aware of it, could you post some links to the topics where it happened, if you don't mind.

In rP22297#34067, @elexis wrote:

It would be much cleaner with: Reflections: None, Sky, Everything.

That'd be cool!

In D1492#83837, @smiley wrote:

1. Look at the date on which this was uploaded
2. Look at what was changed
3. Try to come up with a reason

In D1492#83822, @smiley wrote:

Nobody cares about tiny maps anyway.

Did you reproduce @Itms steps before the patch?

I would certainly hope none otherwise MacOS has been behaving wrong for years.
The only place I can think of that parses strings to number is GUI sizes, which would previously parse things like "3b" as "0" instead of the 'correct' "3". I don't think there's mods or 0 A.D. code that relied on that - and I'm not sure we want that code to live.

Do we really need that behaviour for wrong strings?

How many lines of our code depend on this behaviour (that wrong strings are still parsed)?

I tested, now the reflection works as after my commit.

In D1976#82463, @Stan wrote:

custom color space might be weird, since the following code would be messing it up :P

It depends, because color correction may present on each side: os, gpu driver, monitor.

I think the patch should be tested on multi-monitor environment and with a custom color space.