This Week in D

Dconf 2020 cancelled, Adam plays with terminal gui integration

Blog
Posted 2020-03-09

Due to concerns about the COVID-19 disease spreading, DConf 2020 has been cancelled. I suggest we still write some stuff for it and just share it online!

As for my open source work last week, I merged terminal.d and terminalemulator.d (optionally, via a -version switch) so you can more easily migrate a terminal based application to a GUI window. It isn't quite ready for release yet, but I'll write a bit about it today anyway.

Core D Development Statistics

In the community

Community announcements

See more at the announce forum.

My DConf idea

I think we should do things online over a couple days, perhaps with youtube/livestream presentations with chat, and/or written blogs with comments and an associated video conference.

We can do our internal chats (the so-called "beerconf") online by scheduling some time as well as the external outreach by advertising our livestream sessions for other people to jump into, as well as naturally recording it for later.

About terminal -> gui

My terminal.d is a library for programs targeting a terminal-based UI. It tries to adapt to the user's existing environment - on Windows, it uses the system console host, on Linux, it aims to work with the linux console, xterm, rxvt, screen, dtach, etc., etc., etc. It meets the user wherever they are and offers the best features it can, which sometimes means some graceful degradation.

I've also written my own terminal emulator that provides extended features. Historically, I kept the two codebases entirely separate: terminal.d would not provide any extended feature support.

I recently started changing that: terminal.d now has feature detection and can report if you are using my emulator and methods to easily access them. And now, on top of that, the special -version switch to integrate them can be used to guarantee those features are available - and more.

The way it works is, if using the new compile condition, constructing the Terminal object will also spin up a thread running the GUI terminal emulator, and then hook Terminal's methods through to it. As a result, your program - assuming you consistently used the Terminal object's abstractions (instead of doing std.stdio or whatever), need not know about that extra thread. It treats it the same as any other system console... it just happens to be a fully featured one.

Terminal specifically does not work on pipes. Your program must detect that (there's a helper static method for that) and branch. On the other branch, you can and should use the stdio methods instead of constructing the Terminal object. This means the gui thread is also never constructed... but the gui libraries are still linked in right now. You can dynamically branch on pipe vs non-pipe, but not at runtime for system console vs gui...

The GUI window is also customizable, if you bracket that in static if to detect the compile condition. You can change colors, fonts, default sizes, and perhaps menus soon too. I'm working on the menus now, first making the default ones just save scrollback to file and normal copy/paste context bits.

If you are trying to keep your program usable in either way, you will need to static if or at least some other way to make sure your UI is usable without the customizations. But if you are going to commit, this library and switch can help you get into GUI features without sacrificing your existing command line style architecture.

I'm tempted to go crazier and crazier with adding stuff... but for now I am going to be happy with the basics here just working reliably.

Blog Articles
Page generated by adrdox