mlangkabel/dota_factory
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

place the floating widgets in one ordered pass

Browse Source 
The three widgets over the game world view each cached a rect handed to them by
MainWindow's resize, then re-placed themselves from it. But the build button bar
re-centers on a building unlock and the controls panel re-fits on a 50 ms timer,
neither of which goes through MainWindow, so the rects the others held went
stale -- and each widget re-implemented its own avoidance against them.

They now implement FloatingPanel and are placed in one ordered pass: the bar
takes what it wants, the controls panel steps around the bar, and the selection
panel keeps clear of both. A widget that changed size or visibility publishes
FloatingLayoutInvalidatedEvent instead of moving itself, because what it may
take depends on the widgets placed before it.

The rule they step around each other by is one function in lib, where it can be
tested without a display -- the only way any of this geometry gets automated
cover, screen capture of the world view being blank here.

The selection panel keeps its right edge and its vertical centering, but the
space it centers in is now what its own column has left free rather than the
full-width strip the bar used to reserve. It therefore sits lower than before
where the centered bar does not reach it, and it now clears the controls panel,
which it previously ignored.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
This commit is contained in:
Malte Langkabel
2026-08-08 19:10:00 +02:00
parent 37899ea964
commit e66eb7a81f
17 changed files with 329 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
src/ui/BuildButtonBar.cpp
View File

@@ -24,6 +24,7 @@
#include "DisplayName.h"
#include "EventManager.h"
#include "ExitBuilderModeRequestedEvent.h"
#include "FloatingLayoutInvalidatedEvent.h"
#include "IconCaption.h"
#include "InputMapper.h"
#include "ItemIconCache.h"
@@ -270,15 +271,25 @@ BuildButtonBar::~BuildButtonBar()
unregisterForEvents();
}
void BuildButtonBar::anchorTo(const QRect& worldViewRect)
void BuildButtonBar::placeIn(const QRect& viewRect,
const std::vector<QRect>& /*occupiedRects*/)
{
m_viewRect = worldViewRect;
recenter();
}
if (viewRect.isNull())
{
return;
}
// The layout drops hidden buttons from its size hint, but only once it has been
// re-run: an unlock changes which buttons are shown, and Qt would not get around to
// it before the bar is measured here.
layout()->activate();
int BuildButtonBar::getStripHeightPx() const
{
return height() + kBottomMarginPx;
const QSize barSize = sizeHint();
// Centered, except that a bar wider than the view stays flush with its left edge
// rather than hanging off both sides.
const int x = qMax(viewRect.left(),
viewRect.left() + (viewRect.width() - barSize.width()) / 2);
const int y = viewRect.bottom() - kBottomMarginPx - barSize.height() + 1;
setGeometry(QRect(QPoint(x, y), barSize));
}
void BuildButtonBar::clearActiveButton()
@@ -328,29 +339,11 @@ void BuildButtonBar::updateVisibility()
{
m_buttons[i]->setVisible(m_sim->isBuildingUnlocked(m_types[i]));
}
// A hidden button leaves the row, so the bar has to take up its new width and
// re-center on it (REQ-UI-BUILD-BAR).
recenter();
}
void BuildButtonBar::recenter()
{
if (m_viewRect.isNull())
{
return;
}
// The layout drops hidden buttons from its size hint, but only once it has been
// re-run: updateVisibility() calls this straight after setVisible(), before Qt
// would get around to it on its own.
layout()->activate();
const QSize barSize = sizeHint();
// Centered, except that a bar wider than the view stays flush with its left edge
// rather than hanging off both sides.
const int x = qMax(m_viewRect.left(),
m_viewRect.left() + (m_viewRect.width() - barSize.width()) / 2);
const int y = m_viewRect.bottom() - kBottomMarginPx - barSize.height() + 1;
setGeometry(QRect(QPoint(x, y), barSize));
// A hidden button leaves the row, so the bar takes up a new width and has to be
// re-centered on it -- and the widgets that keep clear of the bar have to be placed
// against that new rect too, so the whole pass is re-run (REQ-UI-BUILD-BAR).
EventManager::getInstance()->sendEventImmediately(
std::make_shared<FloatingLayoutInvalidatedEvent>());
}
void BuildButtonBar::onBuildButton(int index)