New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP - Windows command prompt support #1

Closed
wants to merge 12 commits into
from

Conversation

5 participants
@coreyoconnor
Contributor

coreyoconnor commented Aug 28, 2015

From jpbernardy:

For the next major release of vty windows support is a reasonable goal. The current plan is as follows:

  • Use ansi-terminal package to add an instance of Terminal and DisplayTerminal? that does not depend on terminfo.
  • Use unix-compat
  • Use the backend of haskeline for input. Haskeline has already solved a number of the input issues that are open on vty and has windows support. However the currently exported modules for haskeline do not expose the backend modules. Either that would need to be exposed in the current haskeline package or a new package that is a shared input backend created.
@NightRa

This comment has been minimized.

Show comment
Hide comment

NightRa commented Feb 2, 2015

+1

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Aug 16, 2015

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.

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.

@jtdaugherty

This comment has been minimized.

Show comment
Hide comment
@jtdaugherty

jtdaugherty Aug 16, 2015

Owner

@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 vty-opengl that provided an alternative rendering backend, provided vty exported enough of the Image, Picture, and event loop internals to do it.

Owner

jtdaugherty commented Aug 16, 2015

@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 vty-opengl that provided an alternative rendering backend, provided vty exported enough of the Image, Picture, and event loop internals to do it.

@coreyoconnor

This comment has been minimized.

Show comment
Hide comment
@coreyoconnor

coreyoconnor Aug 17, 2015

Contributor

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

  1. Depend on "vty"

For a User

  1. install application
    • dependency on "vty" induces a "vty" install
    • "vty" configure determines supportable front ends and depends on/configures those.
  2. Run application
    • "vty" figures out most appropriate front end.

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

Something like:

  • front end agnostic code: "vty-core"
  • terminfo specific code: "vty-terminfo"
  • Win32 specific code: "vty-win32"
  • OpenGL+SDL: "vty-opengl-sdl"

"vty" would then contain only:

  • build time logic to determine what frontend libraries should be added to dependencies.
  • run time logic to determine what frontend to initialize and use.

Monolith

  • all code in "vty". Enable/disable modules based on build time logic.

In Conclusion / TL;DR

  1. Supporting Win32 console is my top priority. (Gotta use that new Win10 machine somehow!)
  2. This will smooth the terminal abstractions and the build process.
  3. That will ease adding alternate front ends
  4. ???
Contributor

coreyoconnor commented Aug 17, 2015

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

  1. Depend on "vty"

For a User

  1. install application
    • dependency on "vty" induces a "vty" install
    • "vty" configure determines supportable front ends and depends on/configures those.
  2. Run application
    • "vty" figures out most appropriate front end.

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

Something like:

  • front end agnostic code: "vty-core"
  • terminfo specific code: "vty-terminfo"
  • Win32 specific code: "vty-win32"
  • OpenGL+SDL: "vty-opengl-sdl"

"vty" would then contain only:

  • build time logic to determine what frontend libraries should be added to dependencies.
  • run time logic to determine what frontend to initialize and use.

Monolith

  • all code in "vty". Enable/disable modules based on build time logic.

In Conclusion / TL;DR

  1. Supporting Win32 console is my top priority. (Gotta use that new Win10 machine somehow!)
  2. This will smooth the terminal abstractions and the build process.
  3. That will ease adding alternate front ends
  4. ???

@coreyoconnor coreyoconnor self-assigned this Aug 28, 2015

Add compilation options for windows. Partition platform specific aspe…
…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.

@coreyoconnor coreyoconnor changed the title from Windows command prompt support to WIP - Windows command prompt support Aug 28, 2015

Update compile options for tests for windows.
The tests fail to compile due to a "No such file or directory" error. This appears to be due to the long paths used for compilation. Pushing the changes as is for investigation.
@coreyoconnor

This comment has been minimized.

Show comment
Hide comment
@coreyoconnor

coreyoconnor Aug 29, 2015

Contributor

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.

PS X:\> stack build --test
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
vty-5.5.0: build (test)
Preprocessing library vty-5.5.0...
In-place registering vty-5.5.0...
Preprocessing test suite 'verify-attribute-ops' for vty-5.5.0...
[1 of 3] Compiling Verify           ( test\Verify.hs, .stack-work\dist\x86_64-wi
ndows\Cabal-1.22.4.0\build\Verify.o )
[2 of 3] Compiling Verify.Graphics.Vty.Attributes ( test\Verify\Graphics\Vty\Att
ributes.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\Verify\Graphics
\Vty\Attributes.o )
In-place registering verify-attribute-ops-5.5.0...
[1 of 1] Compiling Main             ( .stack-work\dist\x86_64-windows\Cabal-1.22
.4.0\build\verify-attribute-opsStub\verify-attribute-opsStub-tmp\verify-attribut
e-opsStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-attrib
ute-opsStub\verify-attribute-opsStub-tmp\Main.o )
Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-attribute-op
sStub\verify-attribute-opsStub.exe ...
Preprocessing test suite 'verify-config' for vty-5.5.0...
Preprocessing test suite 'verify-crop-span-generation' for vty-5.5.0...
[1 of 7] Compiling Verify           ( test\Verify.hs, .stack-work\dist\x86_64-wi
ndows\Cabal-1.22.4.0\build\Verify.o )
[3 of 7] Compiling Verify.Graphics.Vty.Attributes ( test\Verify\Graphics\Vty\Att
ributes.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\Verify\Graphics
\Vty\Attributes.o )
In-place registering verify-crop-span-generation-5.5.0...
[1 of 1] Compiling Main             ( .stack-work\dist\x86_64-windows\Cabal-1.22
.4.0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tmp\v
erify-crop-span-generationStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.
0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tmp\Main
.o )
.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-crop-span-generation
Stub\verify-crop-span-generationStub-tmp\.stack-work\dist\x86_64-windows\Cabal-1
.22.4.0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tm
p\verify-crop-span-generationStub.dump-hi: openFile: does not exist (No such fil
e or directory)
ghc: warning: _tzset from msvcrt is linked instead of __imp__tzset

--  While building package vty-5.5.0 using:
      C:\\Users\\coconnor\\AppData\\Local\\Programs\\minghc-7.10.2-x86_64\\ghc-7
.10.2\\bin\\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-pac
kage-db -package-db=C:\Users\coconnor\AppData\Roaming\stack\snapshots\x86_64-win
dows\nightly-2015-08-17\7.10.2\pkgdb\ C:\Users\coconnor\AppData\Local\Temp\stack
9836\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build t
est:verify-attribute-ops test:verify-config test:verify-crop-span-generation tes
t:verify-display-attributes test:verify-empty-image-props test:verify-eval-termi
nfo-caps test:verify-image-ops test:verify-image-trans test:verify-inline test:v
erify-layers-span-generation test:verify-parse-terminfo-caps test:verify-simple-
span-generation test:verify-terminal test:verify-using-mock-input test:verify-us
ing-mock-terminal test:verify-utf8-width --ghc-options -hpcdir .stack-work\dist\
x86_64-windows\Cabal-1.22.4.0\hpc\.hpc\ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1
PS X:\>
Contributor

coreyoconnor commented Aug 29, 2015

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.

PS X:\> stack build --test
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
vty-5.5.0: build (test)
Preprocessing library vty-5.5.0...
In-place registering vty-5.5.0...
Preprocessing test suite 'verify-attribute-ops' for vty-5.5.0...
[1 of 3] Compiling Verify           ( test\Verify.hs, .stack-work\dist\x86_64-wi
ndows\Cabal-1.22.4.0\build\Verify.o )
[2 of 3] Compiling Verify.Graphics.Vty.Attributes ( test\Verify\Graphics\Vty\Att
ributes.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\Verify\Graphics
\Vty\Attributes.o )
In-place registering verify-attribute-ops-5.5.0...
[1 of 1] Compiling Main             ( .stack-work\dist\x86_64-windows\Cabal-1.22
.4.0\build\verify-attribute-opsStub\verify-attribute-opsStub-tmp\verify-attribut
e-opsStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-attrib
ute-opsStub\verify-attribute-opsStub-tmp\Main.o )
Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-attribute-op
sStub\verify-attribute-opsStub.exe ...
Preprocessing test suite 'verify-config' for vty-5.5.0...
Preprocessing test suite 'verify-crop-span-generation' for vty-5.5.0...
[1 of 7] Compiling Verify           ( test\Verify.hs, .stack-work\dist\x86_64-wi
ndows\Cabal-1.22.4.0\build\Verify.o )
[3 of 7] Compiling Verify.Graphics.Vty.Attributes ( test\Verify\Graphics\Vty\Att
ributes.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\Verify\Graphics
\Vty\Attributes.o )
In-place registering verify-crop-span-generation-5.5.0...
[1 of 1] Compiling Main             ( .stack-work\dist\x86_64-windows\Cabal-1.22
.4.0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tmp\v
erify-crop-span-generationStub.hs, .stack-work\dist\x86_64-windows\Cabal-1.22.4.
0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tmp\Main
.o )
.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\verify-crop-span-generation
Stub\verify-crop-span-generationStub-tmp\.stack-work\dist\x86_64-windows\Cabal-1
.22.4.0\build\verify-crop-span-generationStub\verify-crop-span-generationStub-tm
p\verify-crop-span-generationStub.dump-hi: openFile: does not exist (No such fil
e or directory)
ghc: warning: _tzset from msvcrt is linked instead of __imp__tzset

--  While building package vty-5.5.0 using:
      C:\\Users\\coconnor\\AppData\\Local\\Programs\\minghc-7.10.2-x86_64\\ghc-7
.10.2\\bin\\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-pac
kage-db -package-db=C:\Users\coconnor\AppData\Roaming\stack\snapshots\x86_64-win
dows\nightly-2015-08-17\7.10.2\pkgdb\ C:\Users\coconnor\AppData\Local\Temp\stack
9836\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build t
est:verify-attribute-ops test:verify-config test:verify-crop-span-generation tes
t:verify-display-attributes test:verify-empty-image-props test:verify-eval-termi
nfo-caps test:verify-image-ops test:verify-image-trans test:verify-inline test:v
erify-layers-span-generation test:verify-parse-terminfo-caps test:verify-simple-
span-generation test:verify-terminal test:verify-using-mock-input test:verify-us
ing-mock-terminal test:verify-utf8-width --ghc-options -hpcdir .stack-work\dist\
x86_64-windows\Cabal-1.22.4.0\hpc\.hpc\ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1
PS X:\>
@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Aug 29, 2015

Sounds like nice progress!

The stack devs have been talking about windows issues recently, maybe there's some work you can use/share.

Sounds like nice progress!

The stack devs have been talking about windows issues recently, maybe there's some work you can use/share.

coreyoconnor added some commits Aug 30, 2015

Work around path length issues on windows by removing "verify-" from …
…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.
Depend on forks of Win32 and ansi-terminal. These contain changes add…
…ing necessary Console functions to Win32. Incomplete, but enough to get started.

TODO: Pull Request forks prior to merging this branch to master.
Change the DisplayContext to an Operational monad instead of a struct…
…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.
Add MoveCursor and DisplayRowEnd implementations for Win32.
Fixup setting console *output* code page and determining display size.
Add Win32 text attribute handling except for "keep current attribute".
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.
@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Jul 23, 2016

Ping, how is this looking ?

Ping, how is this looking ?

@pavonia

This comment has been minimized.

Show comment
Hide comment
@pavonia

pavonia Aug 20, 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.

pavonia commented Aug 20, 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.

@pavonia

This comment has been minimized.

Show comment
Hide comment
@pavonia

pavonia Sep 14, 2016

The low-level binding is up now (repo here and on Hackage). It's only tested on an old 32-bit WinXP, so feedback on how it works on more recent Windows versions is much appreciated.

pavonia commented Sep 14, 2016

The low-level binding is up now (repo here and on Hackage). It's only tested on an old 32-bit WinXP, so feedback on how it works on more recent Windows versions is much appreciated.

@jtdaugherty

This comment has been minimized.

Show comment
Hide comment
@jtdaugherty

jtdaugherty Dec 4, 2016

Owner

Since this has been inactive for quite a while, I'm closing it - but feel free to re-open if this gets revived!

Owner

jtdaugherty commented Dec 4, 2016

Since this has been inactive for quite a while, I'm closing it - but feel free to re-open if this gets revived!

@jtdaugherty jtdaugherty closed this Dec 4, 2016

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Dec 4, 2016

@jtdaugherty that seems odd, I think I am missing some context. Have you taken over the vty project from @coreyoconnor ? Are you saying windows support is a non-goal, and the work so far should be abandoned ?

@jtdaugherty that seems odd, I think I am missing some context. Have you taken over the vty project from @coreyoconnor ? Are you saying windows support is a non-goal, and the work so far should be abandoned ?

@jtdaugherty

This comment has been minimized.

Show comment
Hide comment
@jtdaugherty

jtdaugherty Dec 4, 2016

Owner

@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!

Owner

jtdaugherty commented Dec 4, 2016

@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!

@coreyoconnor

This comment has been minimized.

Show comment
Hide comment
@coreyoconnor

coreyoconnor Dec 4, 2016

Contributor

I agree with closing this for now. Unfortunately, my current employer severely restricts any and all opensource contributions. I can't participate at this time and will not able to for the foreseeable future.

Contributor

coreyoconnor commented Dec 4, 2016

I agree with closing this for now. Unfortunately, my current employer severely restricts any and all opensource contributions. I can't participate at this time and will not able to for the foreseeable future.

@jtdaugherty

This comment has been minimized.

Show comment
Hide comment
@jtdaugherty

jtdaugherty Dec 4, 2016

Owner

@coreyoconnor - okay, thanks - that's very good to know. I had no idea your ability to contribute was so limited.

Owner

jtdaugherty commented Dec 4, 2016

@coreyoconnor - okay, thanks - that's very good to know. I had no idea your ability to contribute was so limited.

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Dec 5, 2016

I see, thanks for the clarifications. Also I notice this is a PR not an issue. I would still love to have vty & brick on all the major platforms, as would the Windows users I hear from periodically. Hopefully someone will help move @coreyoconnor and @pavonia's work forward soon. :)

I see, thanks for the clarifications. Also I notice this is a PR not an issue. I would still love to have vty & brick on all the major platforms, as would the Windows users I hear from periodically. Hopefully someone will help move @coreyoconnor and @pavonia's work forward soon. :)

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Apr 25, 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."
more

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."
more

simonmichael commented Apr 25, 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."
more

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."
more

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Apr 25, 2017

PS I pledge $50 to get a bounty started for a windows-compatible vty release. [edit: Please add your pledges to this issue to attract devs.]

simonmichael commented Apr 25, 2017

PS I pledge $50 to get a bounty started for a windows-compatible vty release. [edit: Please add your pledges to this issue to attract devs.]

@jtdaugherty jtdaugherty reopened this Apr 25, 2017

@simonmichael

This comment has been minimized.

Show comment
Hide comment
@simonmichael

simonmichael Apr 29, 2017

From haskell-cafe today:

Possibly related are the console changes introduced with Windows 10 Creators Update. A lot of compat issues are said to be resolved. See https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/ for details.

From haskell-cafe today:

Possibly related are the console changes introduced with Windows 10 Creators Update. A lot of compat issues are said to be resolved. See https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/ for details.

@jtdaugherty

This comment has been minimized.

Show comment
Hide comment
@jtdaugherty

jtdaugherty Oct 1, 2017

Owner

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.

Owner

jtdaugherty commented Oct 1, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment