cursor使ってPySideからpywebviewにサクッと書き換えできた、凄い…

PySideで書いてnuitkaでexe化してたツールをcursorでpywebviewに書き換えてもらって起動して見たら起動がクソ早かった。。。今後pywebviewで作るか…

🦅 Dulus 0.2.89 — live on PyPI ✨ Highlights: 🔤 **Local OCR everywhere** - New `/ocr` command and `ExtractTextFromImage` tool — extract text from images via pytesseract (with easyocr fallback). Zero vision tokens, offline, instant. - Use case: receipts, code screenshots, error stacks, dense tables. Anything text-shaped inside an image. 📸 **WebBridgeScreenshot now auto-OCRs** - One tool call returns `{ saved_to, text }`. Model no longer has to chain Screenshot → ExtractText. No more "let me Read this PNG" → 8KB of binary garbage in context. 🖼️ **/img OCR fallback** - Vision models (Claude, GPT-4o, Gemini, etc.) now receive image AND a verbatim text transcription side-by-side. Fewer OCR-style misreads on receipts and code. - Text-only models (or routes where the bridge drops the image) now get the OCR text and can actually answer. Graceful degrade > silent fail. 🦅 **Sandbox embedded inside the desktop GUI** - Click "🦅 Sandbox" in the GUI Web tab → the Dulus OS renders INSIDE the frame, not in a popup window. pywebview spawned as a subprocess, reparented via Win32 SetParent into the tkinter content frame. Production-grade Python desktop integration. - Drag inside the OS doesn't jitter the embed. Opens at GUI's current size, frozen there. - Smart URL: uses `:5000/sandbox/` if /webchat is running (gives full API access), otherwise spins up a local SandboxServer on a random port. Works offline either way. 📚 **kepano/obsidian-skills bundled** - 5 skills shipped out of the box: defuddle, json-canvas, obsidian-bases, obsidian-cli, obsidian-markdown. - Dulus writes Obsidian Flavored Markdown by default — wikilinks `[[Note]]`, callouts `> [!note]`, properties, embeds. Killer pairing: open ~/.dulus/memory as an Obsidian vault and the graph view connects related memories automatically. 🌐 **LiteLLM gateway polish** - One provider entry → 100 backends (OpenRouter, Groq, Together, xAI, Mistral, Cohere, Perplexity, …) - Welcome wizard auto-installs LiteLLM in-place and asks for the backend-specific API key (no more exit-wizard, pip-install, re-run dance). 📦 Install: `pip install -U dulus` 🔗 PyPI: pypi.org/project/dulus/0.2.8… 🔗 GitHub: github.com/KevRojo/Dulus 🌐 Web: kevrojo.github.io/Dulus/ Named after the bird, not the rocket. 🦅🇩🇴 $Dulus $DULUS #Dulus

Raggify .net 版はローカルモデル周りの実装が手に余って検索精度ガタガタに、、 食べ物で検索したらブリッジて😂 結局元の Web 版実装を pywebview でローカルアプリ化する方針に切り替え 見た目は完全維持、しかし今度は windows 移行が原因で推論用ライブラリが激重、、詰みか？！ #SuperDevDay

【朗報】claude codeで｢承認｣押すだけのしょうもない作業、不要になる てことで絶対いいね RTしてください！！ まあ、この動画だけだと何やってんだって話ですが この動画の裏では 1.pywebviewで構成されたGUIがCLIを起動 2.セッション開始時に/remote-control model選択(default:Opus 4.7) effort選択(default:/effort max) 3.CLIの出力を監視し、-rm rfやnpm install、pip install、wingetなど、攻撃を受け得るコマンドを検出してユーザ承認待ちにする それ以外は自動承認 4.role=役職を与えて複数セッションを起動 5.各セッションには各roleに対応した.mdとmanagerセッションから指示として記載される.mdがそれぞれ割り当てられていて、更新を検知したらGUI側で更新内容が適切なセッションのCLIに自動送信される 6.通達内容だけでなくclaude同士の共用フリーボードも存在し、これは誰でも書いたり読んだりすることができる(半ば雑談用、人間の組織でコミュニケーションから生まれるアイデアを再現) 7.GUI CLIの複数セッション間で協調して、人間不在の開発を組織として進める ということをやっています まあOpenClawでいいのかもしれんけど、しょっちゅう方針変わるので作りました 役職は 階級=CCO(もしくは、社長室) CCO(Chief Coordination Officer,Chief Claude Officer):組織全体を俯瞰してユーザーに行動提案を出す PA:秘書、ユーザーが最優先でやるべきことを1つ出す 階級=coordinator(マネージャー) Manager:各セッションの管理職、各セッションに向けて戦略策定やタスクの優先順位付け、品質レビュー、デプロイ判断やマーケティングなどを指示する 階級=Worker 1.戦略策定と分析 PM:何をどういう理由で作るべきかを決定し、これを指示する Analyst:データの集計や分析やA/Bテストの設計などを行い、マーケティングの結果を検証する Revops:価格帯の設計などを行う 2.実装 Developer:コード実装やバグの修正、リファクタリングを行う Designer:UI/UX開発やブランディングなどを行う Docs:ドキュメントの管理やチュートリアルの設計を行う 3.品質保証 QA:品質保証、回帰テスト、クロスプラットフォーム対応などを行う Security:自システムの脆弱性の調査(とにかく悪意を持ってやる) SRE:システム管理と運用タスクの自動化 4.マーケティング Marketing:noteやTwitterの下書き執筆、SEOや、アドセンスの整備 Content:youtube、Shorts、インスタリールの脚本などを書く Growth:世間への広げ方を考える 5.コンプライアンス Legal:日本法を理解して適切なデプロイや表記ができるようにする ちなみに、俺にやるべきことを提示してくれる秘書claudeもいます

我花了一个半月，从零做了一个Web3监控软件 开头先说结论 我是一个独立开发者（虽然不是很高级那种）。我花了一个半月时间，从零开始做了一套Web3 资产监控软件，名字叫“powerpei Web3 哨兵”。 这个软件能监控EVM链和Solana链 它集成了AI交易解读、多渠道推送、链上数据聚合等功能。 我特别喜欢的功能：它可以监控ETH和SOL链上的土狗项目，还能追踪聪明钱包的动向 这个功能让我能实时捕捉到链上的早期机会。 软件已经稳定运行了好1个月 我之前写过一篇技术概述 但是我总觉得那篇文章对核心实现的讲解还不够深入 所以我决定写这篇深度复盘。我会从进程架构、I/O模型、数据一致性、AI工程化等角度，毫无保留地分享那些藏在代码深处的设计决策和实现细节。 我希望这篇文章能帮到那些也在 Web3领域探索的开发者。 --- 一、进程架构：我为什么选择“主进程 多子进程”？ 市面上很多Python监控脚本都是单进程asyncio一把梭 但是我在设计之初就选了“主进程(GUI) 独立子进程（EVM/SOL）”的架构 ➤ 隔离性和稳定性最重要 WebSocket长连接在网络波动时很容易触发异常重连。甚至底层库的C扩展可能因为未知原因崩溃。 如果你把GUI和监控逻辑混在一个进程里，任何未捕获的异常或内存访问违规都可能导致整个桌面应用闪退。 我通过 `subprocess.Popen` 把EVM和Solana监控逻辑独立成子进程 这样做有两个好处： 物理级隔离：`Evm.py` 崩溃或被强制Kill，主窗口依然正常运行。托盘图标不会消失，用户可以点击“启动”重新拉起来。 日志透传：主进程通过管道捕获子进程的stdout 我用 `_forward_output` 线程逐行读取、清洗ANSI 颜色码 然后通过 `window.evaluate_js` 注入前端DOM。这样就实现了日志实时刷新，而且UI线程还保持轻量。 ➤生命周期管理的细节 在 `core_process.py` 中，停止子进程不是简单的 `terminate()`。我实现了一套强杀兜底机制： ```python proc.terminate() proc.wait(timeout=3) if proc.poll() is None: proc.kill() proc.wait(timeout=2) if proc.poll() is None: os.system(f'taskkill /F /PID {proc.pid}') ``` 这套组合拳确保了即使Python解释器卡死，Windows底层也能彻底清理进程树 这样就避免了残留进程占用端口或数据库锁，导致下次启动失败。 --- 二、I/O 模型和高可用连接：不止是asyncio ➢ 混合监控模式：WSS实时 RPC补偿 EVM链的原生币没有标准的Transfer事件日志 你无法通过WSS订阅。 我设计了一个轮询补偿器 它每60秒通过RPC获取 `eth_getBalance`，然后和内存快照对比。差值超过 1e-18就触发推送。 这个机制看起来很简单 但是它其实是WSS订阅失活时的最后一道防线。 对于代币和NFT，系统订阅 `logs`。我精细处理了 ERC1155 的 `TransferSingle` 和 `TransferBatch` 事件 特别是 `TransferBatch`，它的 `data` 字段包含动态数组。我实现了基于 ABI 规范的手动偏移量解析，而不是依赖重型库 这极大降低了解析开销。 ➢ WSS的指数退避和节点热切换 在生产环境中，公共 RPC/WSS节点随时可能限流或宕机。 我在 `chain_wss_monitor_direction` 中实现了节点轮换和重连策略： →节点池：配置文件中为每条链配置多个 `WSS_NODES` 启动时随机或顺序选择一个。 →退避算法：连接断开后，重试间隔从5秒开始，每次翻倍直到60秒 这样就避免了在节点恢复前造成DDoS式的重连风暴。 →国内网络环境适配：系统支持配置本地代理软件的 HTTP 地址 通过 `websockets_proxy` 库把WSS流量转发到代理，恢复和境外节点的稳定通信。 ➢Solana的异步解析流水线 Solana的出块速度极快，而且交易结构复杂 为了避免Helius API调用阻塞WSS消息接收，我设计了一个生产者-消费者解耦模型： →生产者：WSS `logsSubscribe` 收到签名后，立即把它扔进 `asyncio.Queue` 或直接触发一个后台 `asyncio.create_task` →消费者：独立的异步任务负责调用 Helius `/v0/transactions` 接口，解析 `nativeTransfers`、`tokenTransfers`、`events.nft` 等字段。 这保证了WSS连接的 `recv()` 循环永远不会被慢速HTTP 请求卡住 这确保了超高TPS环境下消息的实时性。 --- 三、数据一致性：从内存去重到SQLite约束 ➤ EVM 侧：数据库唯一索引 EVM监控中，同一笔交易可能因为WSS重连、轮询补偿等原因被多次处理。 单纯依赖内存 `set` 无法应对进程重启。所以我设计了 `tx_history` 表的复合唯一约束： ```sql UNIQUE(tx_hash, log_index, address) ``` 任何重复插入都会被SQLite的 `ON CONFLICT IGNORE` 静默丢弃。这从数据库内核层面保证了幂等性。 对于没有 `log_index` 的原生币转账，我降级使用 `tx_hash address` 作为组合键。 ➤ Solana侧：时间窗口内的签名去重 Solana交易没有 `log_index` 概念。而且Helius解析可能产生多条记录。 我使用了内存 `set` 存储最近处理的签名 我利用 `LimitedSizeDict` 的变体思想，在签名集合超过1000个时，自动清空一半（或利用 `OrderedDict` 弹出最旧条目）。 这种滑动窗口去重在性能和准确性之间取得了良好平衡。 --- 四、AI 工程化：多提供商容错和JSON解析的艺术 ➢特征驱动的动态调度 `MultiAIClient` 是 AI模块的核心 它不是简单的if-else分支，而是一个基于特征标志的调度器。 配置文件中定义了每个提供商支持的功能（比如 `transaction_insight`、`daily_report` 等） 当请求解读时，系统会筛选出支持该特征的提供商列表，按优先级发起请求 超时或失败就自动降级到下一个。 ➢ LLM 输出的防御性解析 大模型输出 JSON不稳定是常态。我的处理流程远比 `json.loads` 复杂： 清洗：移除Markdown代码块标记 ```` ```json ```` 和 ```` ``` ````。 正则提取：如果解析失败，我直接用正则表达式 `r'"insight"\s*:\s*"([^"]*)"'` 暴力提取字段。这是最后一道防线。 字段映射：兼容 `insight` / `Insight` / `解读` 等多种Key 命名 这套机制确保了即使Moonshot或DeepSeek返回了“半个 JSON”，前端依然能展示有效解读 它不会抛出 `JSONDecodeError` 导致白屏。 --- 五、内存和性能：LimitedSizeDict和异步队列 ➢ 自定义有限容量字典 Python标准库没有内置LRU而且限制大小的字典 我基于 `collections.OrderedDict` 实现了 `LimitedSizeDict`： ```python def __setitem__(self, key, value): if len(self) >= self.max_size: self.popitem(last=False) # 淘汰最早插入的项 super().__setitem__(key, value) ``` 这个简单的数据结构被用于Token信息缓存、价格缓存、NFT元数据缓存。 它确保了长时间运行时，内存占用不会随着监控地址增多而线性膨胀 内存占用稳定在一个极低水平 ➢Solana 日志的异步串行写入 Solana的详细交易日志需要写入JSON文件 如果多个协程同时 `json.dump`，很容易导致文件格式损坏。 我引入了 `asyncio.Queue`： - 所有写日志请求把数据 `put` 进队列。 - 唯一的一个后台协程 `_file_writer` 阻塞等待队列，取出数据后执行文件I/O。 这既避免了复杂的线程锁，又利用异步特性保证了高并发下的数据安全。 --- 六、前端和后端的双向通信：pywebview的深度集成 ➤ JS API 注入 `pywebview` 允许你把Python对象的方法直接暴露给前端 JavaScript。 我的 `Api` 类继承自多个Mixin 所有以 `def` 开头的公有方法都自动成为 `window.pywebview.api` 的成员。 这让我能以极低成本实现前后端分离。前端只需要关注 UI 交互。 ➤悬浮窗的独立实例和通信 悬浮窗不是主窗口的子DIV，而是 `pywebview` 创建的第二个独立窗口。 我通过 `FloatingWindowManager` 管理它的生命周期。我利用主进程的 `js_api` 实例向悬浮窗注入JS代码（`evaluate_js`） 这实现了主窗口日志向悬浮窗的实时推送。 这种设计保证了悬浮窗即使被关闭，也不会影响主监控任务的运行。 --- 七、桌面应用打包：PyInstaller的深坑和工程化实践 把 Python项目交付给没有技术背景的最终用户，你必须打包成独立EXE PyInstaller看起来是一条命令搞定。但是在复杂项目中，它背后隐藏着无数足以让开发者崩溃的细节。 这一节我分享我在打包“powerpei Web3 哨兵”过程中遇到的几个典型深坑和解决方案。 ➤ 隐式导入和 --hidden-import PyInstaller通过静态分析入口文件的 `import` 语句来构建依赖树。 但是很多库（比如 `pystray`、`websockets`）使用了 `importlib.import_module` 或 `__import__` 动态加载子模块。这导致打包后的 EXE 运行时抛出 `ModuleNotFoundError` 解决这个问题的关键在于根据报错信息反向定位缺失模块 然后在打包命令中显式声明 `--hidden-import`。 比如，这个项目中托盘图标功能必须添加： ```bash --hidden-import pystray._win32 --hidden-import pystray._util --hidden-import win32event --hidden-import win32api ``` 这要求开发者对依赖库的内部结构有一定了解 通常需要结合源码阅读和反复试错才能完整列出所有隐式依赖。 ➤ --collect-all 和资源文件陷阱 `pywebview` 库不仅包含 Python代码 还依赖前端 HTML/JS 以及Edge WebView2 运行时文件。 PyInstaller的默认分析无法感知这些非代码资源 如果你不加处理，打包后程序会因为找不到 `index.html` 或 `webview.js` 而白屏。 正确的处理方式是使用 `--collect-all pywebview` 这个参数强制PyInstaller把 `pywebview` 包目录下的所有文件（包括二进制和静态资源）完整复制到打包目录。 这是处理这类“重型”GUI库的标准操作。 ➤ 二进制依赖和UPX压缩 项目依赖的 `pywin32`、`Pillow` 等库包含 `.pyd` 和 `.dll` 二进制文件。 这些文件体积比较大，而且在PyInstaller打包后不会被自动压缩。 通过集成UPX 工具并在打包命令中指定 `--upx-dir`，你可以对最终 EXE内的二进制文件进行高比率压缩（通常可以缩减 30%-50%体积）。 需要注意的是，极少数老旧杀毒软件可能对UPX加壳的程序产生误报 但是对于技术型用户群体，这种概率极低而且可以通过提交样本解除。 ➤ 路径“冻结”和 sys._MEIPASS 这是PyInstaller打包中最核心的概念 开发阶段，程序通过 `__file__` 或相对路径访问配置文件、图片资源。 打包成单文件EXE 后，所有资源被解压到一个临时目录 这个目录的路径存储在 `sys._MEIPASS` 变量中。 开发者必须在代码中全局替换所有文件访问逻辑。典型范式如下： ```python def get_resource_path(relative_path): if getattr(sys, 'frozen', False): base = sys._MEIPASS else: base = os.path.abspath(".") return os.path.join(base, relative_path) ``` 忽略这个适配会导致程序运行时找不到任何外部文件 这是新手打包时遇到最多的路径地狱 我的做法是把这个函数封装在 `utils.py` 中，全项目统一调用。这确保了打包前后路径行为一致。 ➤子进程的特殊处理 这个系统采用主进程启动子进程的架构。 在打包后，子进程脚本 `Evm.py` 和 `Sol.py` 也被封装在 EXE内部。 如果主进程仍然尝试用 `python.exe Evm.py` 启动，会因为找不到文件而失败。 我的解决方案是在主进程启动子进程时，动态检测是否处于打包模式 然后传递正确的 `--main-exe-dir` 参数，使子进程能定位到配置文件所在的外部目录。 这部分逻辑细节我已经在进程架构章节中讲过了，这里不再重复。 --- 八、最后说几句 我回顾整个开发历程 从单脚本到多进程架构，从裸WebSocket到高可用节点池，从简单的 print日志到结构化 SQLite存储，每一步都是对工程化理解的深化。 打包环节的探索更是让我深刻体会到：能让软件稳定跑起来只是第一步，能让用户轻松用起来才是真正的交付。 这不仅是一个监控工具，更是我在异步编程、进程管理、AI集成、桌面软件开发等领域实践经验的集合。 如果你对文中的任何技术细节感兴趣，欢迎访问我的 GitHub（我在掘金 电鸭 知乎的笔名是 潇楠） --- 作者：Powerpei 全栈 & Web3独立开发者，专注于Python桌面应用、区块链数据分析和AI工程化落地

Python 製のWebアプリを通常のアプリっぽくみせるPWA（Progressive Web Apps）化しようと、pywebviewを使ってますが…… Pyinstaller で動かすと起動時に割とランタイムエラー 出る環境あるので本末転倒な感じがしてきた シンプルに"webbrowser.open"で良いよこれ #ひとりごと

PythonでGUI作るならpywebviewがアツい！ Electronより圧倒的に軽くて、WindowsのEdgeエンジン(WebView2)をフル活用できるのが魅力。HTML/CSSのスキルがそのままデスクトップアプリになります。 導入から実装までまとめました！ niyanmemo.com/7268/ #Python #プログラミング

聊聊桌面开发，我用的是python加pywebview，首先python生态好，啥ai包都有。我自己已经打通了mac打包，公证，windows，msix上架全流程。对我来说用这套框架开发桌面是最舒服。

uvxコマンドで起動できるDjango アプリケーションを作った uvx filechest dir でサーバとブラウザを起動して、ローカル/S3のファイル一覧表示やコピー・移動などができる。uv使うとDjangoでもコマンドにできるの面白い。-g オプションでPywebviewによるGUIとしても実行できる pypi.org/project/filechest/

Eelとかpywebviewとかと同列のライブラリ使ってる人って実際何に使ってるのか知りたいのだ！

PythonスクリプトをGUI化したい？ PyQtは重い、Tkinterは見た目がツラい… そんな人の“隙間ニーズ”を埋めるのがPyWebview。 HTML/CSS/JSで見た目を作り、 Pythonロジックをそのまま使える。 WebのUIで動くデスクトップアプリが作れます。 知ってる人だけ得してる系の技術。 #python

🚀 Introducing LocVi: A Lightweight Local File Browser Tired of the endless hunt through folders? Want to easily preview PDFs, videos, images, and audio files without the clutter? Check out LocVi project built with Flask & pywebview github.com/ullaskunder3/locv…

Grok-4 spent 15x longer (which, sure, is a bit ridiculous) but gave imo a perfect answer, listing webview.h, pywebview, and wry, and a good explanation of each.

「Windowsデスクトップアプリを作るのはもうpywebviewでよくね？」と思って試しにpywebview flaskでカレンダーを書いてみた。ものの数分でできてしまった(カレンダー部分はAIに書かせた)。ただしできあがった.exeファイルは64MBある。 まいっか。

Easy solution: Install simplewebserver -- start it at 3000 - point it to your folder Write a tkinter pywebview script, in python that will load this page and show it to you using webview (you could technically just start flask as well on this could itself to serve your pages) Python can be packaged to exe Alternate option is golang, you can get a clean single exe with that, you can package your html into the single binary as well if you want

最近顺便评测了一下 pywebview，结论不堪大用，除了 webview 自身的兼容性问题外，pywebview 比 electron 更卡，同时缺乏很多必要的支持，比如主窗口没有 native 窗口的 menu，完全无法实现，electron 做这个没问题，同时 pywebview 没有很多系统对话框，比如打开文件，保存问题，要靠 tkinter 实现。

某些安装了比较强力的杀毒软件或者企业安全软件的机器上，webview2 就根本跑不起来，不但 tauri 做的 ChatWise 跑不起来，就连 pywebview 的官方 demo （三行代码哪个）都跑不起来，就一个白色窗口：

没有对比就没有伤害，感受下 React Native 的流畅性，和 webview2 的拉跨，注意拖动改变窗口尺寸时，webview2 的程序 ChatWise / pywebview 都卡的要死，半天才反应得过来，滚动条那些东西都跟不上窗口改变，好像窗口里硬套了一大坨不属于这个窗口的东西一样，而同时 RN 程序却非常丝滑流畅：

うーん、色々後のことも考えると、ReactNativeがいいんだろうけどなー… もちっと簡単な構成にしたいような気もする。 （gradioはあんまり好きじゃない） PyWebview Tkinterとか試してみるかなー。 typescriptのほうが本職だしねー。