In D2207#93410, @wraitii wrote:

As said above this looks good. Some nitpicks:

@wraitii What do you think about the attached patch?

In D2216#92650, @Nescio wrote:

Just let the gui session files use a circular png.

Yeah, with the patch you're able to use whatever background you want. Because everything is transparent except visible by LOS areas.

In D2216#92637, @Stan wrote:

Maybe the mask option could be a setting so that users can hide the minimap as well ? Eventually triggered by a hotkey.

I suppose it's possible by the regular hidden setting.

The problem with such libraries, that an object is allocated in one place, but freed in a completely different place.

The commit broke button hover (in session) and minimap camera dragging (at least on Windows). As far as I see, we shouldn't reset states for visible objects.

@wraitii any thoughts about updated patch? Is it acceptable?

Fixes compiler warnings from @Stan.

In D2196#91706, @elexis wrote:

So the idea is that it should use m_ViewCamera (from rP3405) instead of g_Game->GetView().

Not quite right, m_ViewCamera is the current camera of Renderer (which can be changed during frame rendering, currently for shadow maps), but here we need exact values used for the final frame before postprocessing.

The commit message seems incomplete to me, I don't see any proofs for "so that the 50+ users stop wondering" in the commit message nor the diff description.

Committed cleanups separately in rP22738.

In D2205#91665, @elexis wrote:

But I do remember precisely you recommending me to add if-safeguards for other places in the code even after I mentioned that it's always given, and then you even convinced me that it's a good idea to better be safe than sorry when it comes to null-deref.

I suppose nothing was changed. You have to use safeguards if you don't have guarantees of a pointer lifetime.

In D2205#91651, @elexis wrote:

Fix the problem at the root and everything else follows along.

I can't say that the patch solves the problem at the root. It doesn't solve a real problem of GUI existence but it adds a visual confidence that the interface try/should to guarantee that.

In D2205#91647, @elexis wrote:

If you get a reference you don't even have the thought "Do I need to check for null", whereas it's the first thought if you receive a pointer.
Even more it makes it impossible to check if the reference is null, so you don't have half the code with null checks and the other code without and some other code with ENSURE.
IMO GetGUI isn't adding anything

It answers to the "Do I need to check for null" question as it returns a reference. I'm not talking about how it stores GUI inside.

In D2205#91624, @elexis wrote:

I still didn't claim that this guarantees the lifetime of the CGUI object.
I did and do claim that the lifetime is guaranteed by the way the code is designed and written, namely that GUIObjects are created inside a CGUI and that the CGUI destroys its objects before it is destroyed and that CGUI objects are never moved or to be moved from one GUI to another.

It's not the objection to your patch, it's just a note that reference isn't safe as it may seem.

We usually put NONCOPYABLE in a private section.

In D2195#91620, @Stan wrote:

@vladislavbelov will you fix the uninitialized members ?

@elexis In my opinion yes to mostly all your So this should *. I think it's more clear. But currently I don't see a strong reason to modify the code only for reference <> pointer transformation.

I'd suggest to replace all m_pGUI by GetGUI(), which can return whatever you want. Fo ex:

CGUI& GetGUI()
{
    ENSURE(m_pGUI);
    return *m_pGUI;
}
// or
CGUI& GetGUI()
{
    ENSURE(IsGUIStillValid(m_pGUI));
    return m_pGUI;
}

In D2205#91544, @elexis wrote:

The point is, if you operate a CGUI* then you are not sure if it's allocated or not. But if it always is, then adding safeguards is only adding more code and saving from something that never happens.
The reference expresses that the CGUI is always allocated during its lifetime, thus it is making it even impossible to test if (m_pGUI) or if (pGUI).
The m_pGUI pointer exists since rP74.
The commit mentioned in the summary changed it so that CGUI is allocated on init rather than some cycles later (which is even making it faster, since the value is directly assigned to the correct pointer instead of to nullpointer and then to something else), aside from making it easier for all the users to consider it.
If you look at that commit referenced in the summary, you will see the previous cases in which it was set.
SetGUI was called on AddScrollBar, on CGUIDummyObject creation, for every child object created in AddObject, and prior to RegisterScriptHandler.

As far as I understand the patch the changes only shows to readers that the m_pGUI member can be used without the safeguard. It doesn't guarantee real lifetime of the CGUI object, as it's created on heap.

Another opinion:
https://google.github.io/styleguide/cppguide.html#Reference_Arguments

In D2205#91525, @elexis wrote:

From my experience such kind of changes doesn't really improve a code and usually adds some difficulty.

Using a reference removes the difficulty here.

I didn't find storying of reference in gui objects before. So it seems that you already implicitly added a strict property to GUI objects.

we do not need to check whether the CGUI page exists or not.

Reference doesn't guarantee that. From my experience such kind of changes doesn't really improve a code and usually adds some difficulty.

In D2196#91405, @wraitii wrote:

Looks alright, but calling it a 'refactoring' is a bit misleading imo, I'd avoid it in the commit message :)

I can't say that it's a bug fix or a cleanup. What's about "Uses correct clip planes values in PostProcManager"?

Why CGUIString, but _GUItext? Maybe rename that too?

Could you add a context to the patch?

Why not to use std::fill? Does it produce the warning?

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?