在dots-hyprland项目中实现Chrome通知图标持久化方案

问题背景

在基于Hyprland的桌面环境中，用户经常遇到Chrome浏览器通知图标无法持久化的问题。当系统重启后，Chrome会删除临时缓存中的图标文件，导致通知中心无法正确显示应用图标。这个问题尤其影响用户体验，特别是对于那些依赖浏览器通知功能的用户。

技术分析

通知系统工作机制

现代Linux桌面环境通过D-Bus的org.freedesktop.Notifications接口处理通知。当应用发送通知时，会包含以下关键信息：

• 应用名称和入口
• 通知标题和正文
• 图标路径（通常位于临时目录）
• 其他提示信息（hints）

Chrome浏览器的特殊行为

Chrome浏览器在处理PWA（渐进式Web应用）通知时有两个特点：

1. 将图标存储在临时目录（如/tmp/.com.google.Chrome.*）
2. 在系统重启或浏览器关闭后会清理这些临时文件

现有解决方案的不足

项目原本的通知处理逻辑直接从hints.image_path获取图标路径，但这种方式存在两个问题：

1. 临时文件会被Chrome清理
2. 部分浏览器（如Zen）使用不同的图标存储机制

解决方案实现

持久化存储方案

通过将临时图标文件复制到持久化目录实现图标保留：

const persistentDir = `${GLib.get_home_dir()}/.cache/ags/notifications/chromium`;

if (!GLib.file_test(persistentDir, GLib.FileTest.EXISTS)) {
    GLib.mkdir_with_parents(persistentDir, 0o755);
}

if (notifObject.hints?.image_path?.deepUnpack) {
    const tempPath = notifObject.hints.image_path.deepUnpack();
    const iconFileName = GLib.path_get_basename(tempPath);
    Utils.execAsync([`bash`, `-c`, `cp ${tempPath} ${persistentDir}/${iconFileName}`])
    
    const imagePath = `${persistentDir}/${iconFileName}`;
    // 使用持久化路径创建图标组件
}

多浏览器兼容处理

针对不同浏览器的通知特性，需要实现差异化的处理逻辑：

const NotificationIcon = (notifObject) => {
    // 优先检查hints中的image_path
    if(notifObject.hints?.image_path?.deepUnpack) {
        // 持久化处理逻辑
    }
    
    // 其次检查直接image属性
    if (notifObject.image) {
        // 标准处理逻辑
    }
    
    // 最后回退到应用图标
    // ...
};

Chrome通知内容优化

针对Chrome通知中多余的HTML内容和URL信息，添加了专门的过滤函数：

function processNotificationBody(body, appEntry) {
    if (appEntry?.toLowerCase().includes('chrome')) {
        return body.split('\n\n').slice(1).join('\n\n');
    }
    return body;
}

实施效果

1. 图标持久化：重启后仍能正确显示通知图标
2. 多浏览器支持：兼容Chrome、Zen等不同浏览器的通知机制
3. 内容优化：过滤了Chrome通知中不必要的HTML标记和URL信息
4. 性能优化：通过缓存机制减少重复文件操作

最佳实践建议

1. 定期清理旧的缓存图标文件，避免占用过多磁盘空间
2. 考虑为不同类型的应用实现不同的图标处理策略
3. 可以扩展支持更多浏览器的特定通知格式
4. 添加错误处理机制，应对文件操作失败的情况

这个方案不仅解决了原始问题，还为通知系统的扩展性打下了良好基础，可以作为类似桌面环境通知处理的参考实现。