Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP - Windows command prompt support #1
For the next major release of vty windows support is a reasonable goal. The current plan is as follows:
Is this still reasonable ? hledger would use it.
As an alternate route, I wondered how feasible it would be to build a fake terminal on top of OpenGL, which seems to be pretty well supported on all platforms. In my dream world, such a terminal could also render as quickly as the memory mapped displays of early home computers.
@coreyoconnor - can you provide an estimate of how much work you think this might be? Since this ticket is four years old, is it realistic to keep this ticket open? (This sounds like a ton of work to me and I know I don't have enough time for it.)
On OpenGL: I could see there being a package
This is a bit of an essay so.....
Still a Good Idea
This is still reasonable and definitely a goal. I investigated Win32 support this weekend and am confident nice support is doable. However, there are an annoying build aspects to this.
On a high level, vty is set up to be abstract from the particular terminal's interface. This was to support the Win32 console functions (in addition to other frontends).
However, I haven't been able to get GHC to link against these functions. I'm missing some critical information on how GHC works on windows. I'll see if I can get some sample programs up somewhere. Hopefully somebody can figure out what I'm doing wrong... Something silly I'm sure!
The terminal abstraction might need some work, but nothing I wasn't planning on doing anyways because... Alternate front ends! Let's make some!
OpenGL+??? / HTML+WebSocket
I'm more interested in building a HTML/HTTP/WebSocket frontend for Vty than an OpenGL one. OpenGL itself only covers: once an output context is acquired how to display the content. OpenGL does not cover: How to acquire a context; How to acquire input events; How to display text. Doable, but not something I want to invest in over HTML/WebSockets.
EG: With HTML I can easily say: "Display this text with these exact dimensions using whatever font that supports the characters requested. Prefer typefaces according to the following priority...." An OpenGL frontend would be faster, but I'd be duplicated a lot of the stuff I get "for free" with HTML.
That said, creating a new OpenGL based terminal optimized for VTY would be awesome as well! :-)
Alternate Front End Usage
Regardless: I'm interested in how would multiple frontends would work from a development/user perspective.
Ideal Scenario: Full Auto
An application using vty would, hopefully, only need to care about depending on vty. No consideration of what front end the user has configured.
For an Application Dev
For a User
Wouldn't that be nice?
For a VTY Dev
For a vty developer, how would the vty development be set up to support multiple front ends?
Common core, one lib per frontend
"vty" would then contain only:
In Conclusion / TL;DR
Darn. I hit a speed bump. The distro of GHC for windows I'm using (ghc 7.10.2 mingw) appears to have a path length limit. Compiling the tests happens to use paths > 260 characters. Which are resulting in false "file not found" error.
Filed a ticket with minghc team:
I've reduced the length of the test names. Which works around the issue.
referenced this pull request
Jul 23, 2016
Not sure how much of the functionality you've already got working for the Windows backend, but I'm currently working on a binding to the Windows console API for one of my projects, too. Maybe I could extend the binding part a bit and make it an extra package if it would be of help for vty. I'm not in a big hurry with my project, though, so it could take several weeks til it would be finished.
@simonmichael Yeah, I've been maintaining Vty in Corey's place for several months now. This pull request has been open for a long time without any activity, and it's my opinion that these things should be closed and later reopened rather than languishing open forever. The same goes for tickets.
By closing this I'm not making a statement about Windows support. Although it is not something I personally plan to pursue myself, I would certainly be happy if these patches were finished up and deemed ready to merge!
referenced this pull request
Mar 5, 2017
Gathering some notes for anyone working on this:
vty is a nice full-screen curses-style API, and the basis for the nice higher-level brick TUI (text UI) framework, that builds on POSIX platforms only. All agree that it would be nice to make it work on Windows too. This would allow building cross-platform TUIs with haskell. Also there are things in vty, such as Graphics.Vty.Attributes, that would be useful for CLIs too.
https://github.com/jtdaugherty/vty/tree/issue-1-windows-console is @coreyoconnor's work towards windows support. "I investigated Win32 support this weekend and am confident nice support is doable." "will not able to [participate] for the foreseeable future."
https://hackage.haskell.org/package/Win32-console is @pavonia's windows console api which might be a useful building block. "It's only tested on an old 32-bit WinXP, so feedback on how it works on more recent Windows versions is much appreciated."
From haskell-cafe today:
Since our efforts to revive this didn't get any takers, I'm closing this again. I don't like to have open PRs linger and this one isn't getting any attention. In addition, I suspect that at this point the best approach to move forward on Windows support would be to start over anyway.