rjkroege/edwood

Make plan9port dependency optional by default

fhs opened this issue · 3 comments

fhs commented

This issue tracks various issues that are preventing us from removing plan9port as a default dependency.

devdraw:

  • duitdraw is slow. In X11, pprof points to swizzle as the primary culprit.
  • segfault on resize in macOS: golang/go#12718
  • duitdraw is missing MoveTo and/or SetCurosor in Windows and macOS
  • In X11, clipboard is used for snarf/paste but not primary selection
  • Support for $PLAN9/lib/keyboard input
  • xauth issue when running tests using duitdraw in Travis CI?

9pserve:

fontsrv:

  • freetype crashes sometimes: ktye/duitdraw#17
  • uncompressed Plan 9 fonts served by fontsrv can't be loaded by plan9font (used by duitdraw)
pf10 commented

is it possible to keep plan9port as an optional alternative to whatever go-only solutions being implemented?

standalone devdraw allows for network transparent gui. right now it's possible to multiplex remote unix duit apps into a plan9 terminal, or do a remote connection to an app from any mac or unix. outside of windows plan9port is likely to be present in all the acme deployments since it provides significant infrastructure that's not reproducible in Go right now (though various utilities are being rewritten).

I guess a bigger question that should be addressed to the duit community, is the duitdraw going to remain feature compatible with plan9 draw protocol. with such a tight integration there's a temptation to ignore existing capabilities and hack something fancy, that would be difficult to retroport into plan9 draw protocol. is there edwood developer position on this question?

thanks!

fhs commented

I wasn't thinking of network transparency. I don't mind keeping plan9port dependency for that.

I guess what I really meant is that go get ... shouldn't require the user to install plan9port. We'd use duitdraw or whatever other native Go GUI library by default and make plan9port dependency optional with a build tag. Right now it's the other way around: we use devdraw by default and enable duitdraw with a build tag.

pf10 commented

I agree an out-of-the-box working editor, that doesn't require complicated dependencies is an excellent goal :) just hoping that the power users are not lost in the process. even just generally having some clarity on the question helps. right now one of the greatest accidental advantages of duit is that it's network transparent, and it's pretty easy to write a custom backend for it. i have a pile of hacks that let me devdraw to a linux framebuffer for example, which i use for kiosks and interactive installations. being able to popup an edwood window to do some live debugging is a cool feature. but i can also see how that's a very niche application.