fix(views): adaptive width layout for remote management

[add-uos]

Remove hardcoded width values and use dynamic width calculation to support adaptive layout in remote management panel.

移除硬编码宽度值，使用动态宽度计算，支持远程管理面板自适应布局。

Log: 修复远程管理面板布局自适应问题
PMS: BUG-361273
Influence: 修复后界面元素能够根据容器大小自适应宽度，提升不同分辨率下的显示效果。

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeex，很高兴为你审查这段代码。

整体来看，这次代码变更的核心目的是将UI控件从固定尺寸/硬编码尺寸改为动态自适应尺寸。你移除了大量如 218、358、360 这样的硬编码魔法数字，转而使用 rect().width() 和布局的拉伸因子，这是一个非常棒的改进！这不仅能更好地适应不同分辨率的屏幕，也为未来的紧凑/宽屏模式切换打下了良好基础。

不过，在语法逻辑、代码质量和性能方面，还有一些值得注意和优化的细节。以下是我的审查意见：

1. 语法与逻辑

• QRect 边界计算存在潜在逻辑偏差（重要）
  在 focusframe.cpp 中，你使用了 QRect(2, 2, qMax(0, rect().width() - 4), qMax(0, rect().height() - 4))。
  从逻辑上看，你想绘制一个距离原控件四周各 2px 的矩形，这个计算是正确的。但是，Qt 提供了更语义化且不易出错的 API：QRect::adjusted(top, left, bottom, right)。
  建议修改为：

  // 旧代码
  paintRoundedRect(FramePath, QRect(2, 2, qMax(0, rect().width() - 4), qMax(0, rect().height() - 4)));
  // 新代码
  paintRoundedRect(FramePath, rect().adjusted(2, 2, -2, -2));

  理由：adjusted 的语义更清晰（左上角各加2，右下角各减2），不需要手动计算宽高，且 Qt 内部会自动处理负值等边界情况，这正好也是你之前 TODO 注释中提到想要兼容的写法。

• 变量名遮蔽
  在 focusframe.cpp 的 paintEvent 中，if (hasFocus()) 分支里定义了 QPainterPath itemBackgroudPath;，而在 else 分支里又定义了同名变量 QPainterPath itemBackgroudPath;。虽然 C++ 作用域允许这样做，但这是典型的变量名遮蔽，容易引起混淆，且拼写存在小错误（Background 拼成了 Backgroud）。
  建议：由于两者在不同分支，可以直接重用外层变量名，或者修正拼写。如果重用，可以在 if/else 之前声明 QPainterPath path;。

2. 代码质量

• 硬编码的布局边距和尺寸
  在 itemwidget.cpp 中，依然残留了一些硬编码数字：

  setMinimumWidth(220);
  setFixedHeight(60);
  m_firstline->setMaximumWidth(138);
  m_funcLayout->setContentsMargins(5, 0, 10, 0);
  m_funcLayout->setSpacing(5);

  建议：建议将这些具有特定业务含义的数字提取为常量（如 static const int s_MinItemWidth = 220;），或者与文件中已有的 s_ItemHeightCompact 等常量保持一致的管理风格。这能大大提高代码的可维护性。

• 版权年份更新
  你将 SPDX-FileCopyrightText: 2022 更新为了 2022 - 2026。
  提醒：通常开源协议的版权年份应该是对应代码修改的真实年份，或者写为 2022 - present。写死为 2026 可能会导致明年还需要再改一次，建议确认项目的版权规范。

3. 代码性能

• paintEvent 中的对象复用
  在 focusframe.cpp 中，每次 paintEvent 触发都会构造 QPainterPath 和 QPen 等对象。
  建议：对于简单的绘制，当前写法没有问题；但如果 FocusFrame 被大量实例化（例如在几百项的列表中），频繁的内存分配可能会带来微小的性能开销。如果性能敏感，可以考虑将 QPainterPath 的计算缓存起来，仅在 resizeEvent 时更新路径。不过若当前绘制流畅，保持现状亦可。

• 布局拉伸因子的调整
  你将 m_mainLayout->addLayout(m_textLayout); 改为了 m_mainLayout->addLayout(m_textLayout, 1);，移除了最后的 m_mainLayout->addStretch();。这是一个很好的性能和布局逻辑优化，让文本布局能够真正占据剩余空间，而不是被固定宽度挤压。

4. 代码安全

• 越界保护（已做，值得肯定）
  你在计算 QRect 宽高时使用了 qMax(0, rect().width() - 4)，这非常棒！这防止了当控件极度小（如 width < 4）时，QRect 接收到负的宽高导致绘制异常或底层渲染崩溃的问题。
• 无明显安全漏洞。UI 布局代码通常不涉及内存越界读写或注入风险，当前改动是安全的。

---

综合修改建议代码片段

针对 focusframe.cpp 的 paintEvent，我建议的最终优化版本如下：

void FocusFrame::paintEvent(QPaintEvent *event)
{
    Q_UNUSED(event)
    // 开启抗锯齿
    QPainter painter(this);
    painter.setRenderHint(QPainter::Antialiasing);

    DPalette pa = DGuiApplicationHelper::instance()->applicationPalette();

    if (hasFocus()) {
        // qCDebug(views) << "Branch: Focus is active";
        // 边框：使用 adjusted 更加安全且语义清晰
        QPainterPath FramePath;
        paintRoundedRect(FramePath, rect().adjusted(2, 2, -2, -2));
        
        // 获取活动色
        QPen pen(pa.color(DPalette::Highlight), 2);
        painter.setPen(pen);
        painter.drawPath(FramePath);

        // 绘制背景
        QPainterPath itemBackgroundPath;
        paintRoundedRect(itemBackgroundPath, rect().adjusted(4, 4, -4, -4));
        
        // ui要有框，背景不变
        painter.fillPath(itemBackgroundPath, QBrush(pa.color(DPalette::ItemBackground)));
    } else {
        // 焦点不在，不绘制边框，仅绘制背景
        QPainterPath itemBackgroundPath;
        paintRoundedRect(itemBackgroundPath, rect()); // rect() 本身就是控件完整尺寸
        
        // ui要有框，背景不变
        painter.fillPath(itemBackgroundPath, QBrush(pa.color(DPalette::ItemBackground)));
    }
}

对于 itemwidget.cpp，你的改动方向非常正确，只需考虑将硬编码数字提取为常量即可。希望这些意见对你有所帮助！

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: add-uos, lzwind

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[add-uos]

/merge