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
…cts to platform specific modules. Minor re-arrangements. Add stub implementations for windows constructors: inputForConfig, outputForConfig. These are only the changes required for the library to compile on windows. Nothing more. The tests, for instance, do not compile.
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.
…all test names. Mapping the repo to a drive letter is also required. All tests will compile. All but 1 test fails. The failures are all of the form "Test suite _ executable not found for vty". All the tests that fail are using detailed-0.9.
…ing necessary Console functions to Win32. Incomplete, but enough to get started. TODO: Pull Request forks prior to merging this branch to master.
…ure of equations that produce Write values. The interpretation of the DisplayCommands is left to the platform. On POSIX platforms the DisplayCommands are interpretted to Write values. No Windows implementation. According to the terminal test and mock-terminal tests the performance is worse than before. I am unable to locate the source of the performance issues.
Fixup setting console *output* code page and determining display size.
The output matches the terminfo output except: Double Column Characters are rendered single column; Instead of the default attribute white/black is used. Correcting the default attribute handling is a straight forward application of Reader. I have not found a way to correct double column character support.
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!
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.
2015: 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."
2016: 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.