https://github.com/migueldeicaza/TermKit

Terminal Kit - Console UI toolkit for Swift applications
https://github.com/migueldeicaza/TermKit

curses gui swift terminal toolkit

Last synced: 3 months ago
JSON representation

Terminal Kit - Console UI toolkit for Swift applications

• Host: GitHub
• URL: https://github.com/migueldeicaza/TermKit
• Owner: migueldeicaza
• License: mit
• Created: 2019-04-05T21:15:09.000Z (over 5 years ago)
• Default Branch: main
• Last Pushed: 2022-12-15T20:37:47.000Z (almost 2 years ago)
• Last Synced: 2024-04-14T12:21:44.882Z (7 months ago)
• Topics: curses, gui, swift, terminal, toolkit
• Language: Swift
• Size: 3.4 MB
• Stars: 446
• Watchers: 16
• Forks: 14
• Open Issues: 33
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        


# TermKit - Terminal UI Toolkit for Swift

This is a simple UI Toolkit for Swift, a port of my [gui.cs library

for .NET](https://github.com/migueldeicaza/gui.cs).   While I originally

wrote gui.cs, it has evolved significantly by the contributions of

Charlie Kindel (@tig), @BDisp and various other contributors - this port 

is bringing their work.

This toolkit contains various controls for build text user interfaces

using Swift.

You can [checkout the documentation](https://migueldeicaza.github.io/TermKit/index.html)



# Running this

From the command line:

```

$ swift build

$ swift run

```

From Xcode, if you want to debug, it is best to make sure that the

application that you want to Debug (in this project, the "Example"

target is what you want) has its Scheme for Running configured

like this:

     * Run/Info: Launch "Wait for Executable to be launched"

Then, when you run, switch to a console, and run the executable, I have my

global settings for DerivedData to be relative to the current directory,

so I can run it like this:

```

$ DerivedData/TermKit/Build/Products/Debug/Example

```

The location for where your executable is produced is configured in Xcode/Preferences/Locations,

I just happen to like project-relative output like the example above shows.

# Debugging

While debugging is useful, sometimes it can be obnoxious to single step or debug over

code that is called too many times in a row, so printf-like debugging is convenient.

Except that prints go to the same console where your application is running, making this

experience painful.

In that case, you can call `Application.log` with a message, and this message will use

MacOS `os_log`, which you can then either look for in the Console.app, or you can monitor from 

a terminal window like this:

```

$ log stream --style compact --predicate 'subsystem == "termkit"'

```