HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
86% Positive
Analyzed from 575 words in the discussion.
Trending Topics
#file#linux#windows#python#fair#though#open#language#don#llm

Discussion (32 Comments)Read Original on HackerNews
This looks great though. +1 choosing Qt instead of Electron. -1 for Python though. Otherwise, your approach ticks most of my boxes.
One feature I'd like to see though is reverse file associations - basically associate Linux filetypes inside the Windows VM so that any file you open in a Windows app would open the file in Linux, assuming Linux has a file association for it. Say I've installed Directory Opus in the VM and I want to use it as my primary file manager in Linux, and say I double-click on a .xml file, I would like to open it in the Linux app associated with that filetype (which would be Kate in my case).
On Python: fair pushback. Picked it for stdlib coverage (zero runtime deps on 3.11+, one tomli fallback for 3.9/3.10) and iteration speed. Heavy lifting is in the container and FreeRDP so perf hasn't been the bottleneck, but yeah the language choice is a tradeoff.
Reverse file association is interesting, hadn't thought about that direction. The v0.3.0 agent could probably handle it but I'd want to look at the security model first. Marking it TBD. If you open an issue with the use case that'd help me scope it.
Can we take this to mean that GPU passthrough is planned? This would be huge especially for running Adobe/Canva software.
https://news.ycombinator.com/newsguidelines.html
https://en.wikipedia.org/wiki/AAlib