Sunday, June 29, 2014

Help Final Term Now and Earn Hard Cash

No, this isn't a scam :) It's much simpler than that.

Following this latest nudgeFinal Term is now on Bountysource, allowing anyone (including you!) to either incentivize bug fixing or earn money fixing bugs (or both).

This was not an easy decision to make but the pressure got to me in the end. I have repeatedly voiced my opposition to accepting donations or running a fundraiser for Final Term, the reason being that what keeps me from developing the project at higher speed is not a lack of money but a lack of free time, and accepting money for what I am happy to do for free will unfortunately not give me any more time for development than I spend already. This stance has not changed; in particular, I still have no intention of taking money in any form for my work on Final Term for the foreseeable future.

But I don't mind if someone else does. In fact, it would make me very happy if that meant more third-party contributions.

While Final Term is lucky enough to have attracted a good amount of valuable community contributions in the past year (most of which are described in this blog), the project's pace is still very much tied to my own schedule. With certain unforeseen real-life obligations that I incurred recently, this can mean that there is sometimes not a single commit in two months, which pains me to see as I want nothing more than to get a stable version of Final Term out into the wild so it can at last start to serve as a useful tool rather than just a cool tech demo. Although I plan to continue putting as much effort into Final Term as my spare time allows, at its current pace completion of the first stable stable version might be pushed well into 2015.

Not a week goes by without me receiving 5-10 mails asking me about the status of the project, when feature X will be done or bug Y will be fixed. By now I have a copy-and-paste response explaining some of the reasons for the slow development pace, how I hope it will all be faster soon and how the project is very much not dead, but I realize this is unsatisfactory in the long run.

As of right now, if you want to see Final Term completed as much as I do, there are two ways for you to help:

Fix bugs. Final Term's issue tracker on GitHub should give you a good idea where to start. In particular, the "Initial Stable Release" milestone contains those issues that are critical for a first release to be attempted. Favorites here include the lack of copy & paste as well as the incomplete xterm emulation. Final Term is developed fully in the open and I will gladly accept any quality pull request, and immortalize the author in Final Term's about dialog, irrespective of the size of the contribution. And repeating the original message of this post: You can now earn money fixing certain bugs, such as and . Please contact me if you are considering a fix for a complex issue requiring deep changes such as copy & paste so we can make sure that your ideas are in alignment with upcoming architectural changes.

Place bounties. Short on time, but still want to see your pet issue getting fixed? Pay someone else to do it! Using Bountysource is easy (took me less than one minute to place the $50 bounty mentioned above) and safe (they accept PayPal). If an issue gets fixed as a result of a bounty placed by someone else, I will list that person in a "development sponsored by" section in Final Term's about dialog (this also applies for companies, of course).
Ah, and one more thing: I stated above that I have no intentions of taking money for my own work on Final Term, and I mean it. Therefore, if I fix an issue that has a bounty attached to it, I will not claim that bounty. I see bounties as a way to attract new contributors, rather than filling my purse in exchange for work I was going to do anyway. So if you put a bounty on an issue I fix eventually, not only will you get your fix, but your money back also!


Please understand that at this time, all bounties have to be attached to concrete issues (if your issue does not exist yet, you are of course welcome to file it). The Final Term project as a whole does not accept bounties or donations at this time. This is not a fundraiser.


Your help is needed to boost Final Term's development speed and get this terminal to the people. Spread the word!

Tuesday, January 14, 2014

The Marriage of Terminal and Shell

The past week has been an exciting one, bringing three key advancements to the interaction between Final Term and bash that I will describe in this post. Together with the extensive existing entanglements, these will be the foundation the initial stable release of Final Term builds on – a marriage of terminal and shell.


precmd and preexec

Final Term now makes use of Glyph Lefkowitz's ingenious script to emulate zsh's precmd and preexec functions, directly extracting the executed command from bash's history.

This fixes a number of bugs in command detection and enables things that would have been near impossible using the previous approach, such as correctly detecting multi-line commands.

Also, since zsh already supports precmd and preexec natively, this suggests a natural route towards zsh support for Final Term. Yes, you heard me right: zsh support is coming. Not very soon maybe (unless someone contributes it) but it will definitely happen, and could be as easy as a port of bash_startup.in to zsh. The obstacles are gone.


Return Codes, Visualized

A picture is worth a thousand words:


Final Term's collapse buttons now double as visual indicators of the associated command's exit status! They glow red if the return code is not zero, traditionally indicating an error. On hover, the exact return code is shown in a tooltip. Final Term hides all the complexity which makes that unique feature possible from the user and only shows the interesting information.

It's pretty cool, I think :)


A World of New Possibilities

This change is the big one.

Connoisseurs of Final Term's internals already know that most of its frontend magic (such as buttons over filenames in ls) is achieved through custom escape sequences in program output that are interpreted by Final Term. This idea has now been taken further: Escape sequences can now trigger Final Term commands (already heavily used in key bindings and text menus). One of the immediate consequences is that Final Term can now be controlled by the programs running inside it simply through escape sequences, no matter what language those programs are written in.

Let me say that again:

Final Term can now be scripted in any language!


The possibilities that this approach allows appear endless, but what is it really useful for? As both an example and a very useful addition, I have implemented another feature that completes the marriage of terminal and shell and showcases how incredibly powerful Final Term has become: Terminal commands.

Terminal commands are shell commands that are executed by Final Term. You define them simply by editing a .ftcommands file. Final Term's shell startup script then reads that file and registers the appropriate aliases (with a "," prefix to avoid name collisions with other shell commands) with the shell, tying them to the relevant Final Term commands which will be relayed to the terminal when the aliases are used.

Terminal commands remain shell commands, which means that they

  • Can be chained and piped with other terminal and shell commands
  • Show up in the shell's history
  • Are completed by the shell's tab completion
  • Accept shell command line arguments

What does this all mean for the user? Have a look:


What's going on here? We first define a bash alias cdtab that consists of a terminal command, ,tab (which, you guessed it, opens a new tab) and a shell command, cd. Running that command has an effect similar to the "open in new tab" middle click that browsers provide. Afterwards, we showcase the ability of terminal commands to accept command line arguments by opening four tabs at once with ,tab 4 (this suggests an obvious way to save tab and pane arrangements, of course).


I am very much looking forward to see what the community does with these new possibilities. Final Term is alive and kicking, and on the finish line towards its initial release and wide availability.


The project still needs help, though. If you have not so far, please consider contributing to the project by testing or coding. I develop and manage this very complex project in my free time exclusively, and could really use some assistance (I'd be glad to provide hints if you are unsure where to start).

And please, as always, do remember that despite all those cool features, Final Term is still unstable and NOT READY for production use.

Friday, October 18, 2013

Multiple Terminals, Final Term Style

Today, I am proud to introduce the most exciting new feature Final Term has gained since its initial announcement in May: Multiple terminals in one window. But allow me to start by explaining how we got there.

The Competition

Your most basic terminal emulator shows one terminal per window that completely fills it:

st

This is what xterm does, and suffices for many users and use cases, which is why that beautiful, minimalistic view is and always will be what Final Term shows by default.

However, for power users administering multiple servers simultaneously this is clearly not enough. Such people are forced to either open multiple instances of the emulator, or use one of the more sophisticated options available.

The first of those is the tabbed terminal, as seen in most GUI terminal emulators in common use today:

GNOME Terminal

Using tabs for multiple document views is a relatively new concept that was popularized by web browsers. It combines ease of switching with maximum space utilization and the ability to provide a limited peek (the tab title) of what is happening inside a terminal that is not currently focused.

The major disadvantage is that you cannot see multiple terminals at the same time without opening multiple windows, a limitation shared with the "basic" approach described above.

Enter the split terminal:

Terminator

Split terminals allow the user to create a flexible arrangement of terminals by recursively splitting existing ones either horizontally or vertically. Terminator combines that feature with GNOME Terminal's tabs, resulting in a tabbed terminal where each tab's view can additionally be split as desired. This is a very powerful approach indeed, and unsurprisingly, Terminator is the terminal of choice for many Linux professionals.

For Final Term's implementation of multiple terminals, I was therefore looking for something at least as powerful...


Infinite Descent

re·cur·sion (n): See recursion.
This is how a popular joke, found in many computer science textbooks, goes. Joking aside, recursion is one of the most powerful concepts in programming. In Terminator, it allows the user to specify a more-or-less arbitrary configuration of split terminals with two simple operations: Split Horizontally and Split Vertically. Thinking about that approach, I realized it could be extended to include tabs in the recursion as well.

Consider an abstract widget called, say, NestingContainer, which can hold one or multiple child widgets in one of the following three configurations:

  1. Base: The container contains one child widget and nothing else
  2. Split: The container contains a split view containing one child widget in each of its two panes
  3. Tabbed: The container contains a tabbed view containing one child widget in each of its tabs

Imagine further that a user-accessible mechanism exists that allows one to switch between these configurations. The power of NestingContainer becomes apparent if the child widgets are themselves NestingContainers, for then the process of splitting and tabbing can be applied recursively, making any combination of the two possible, including many that are not achievable by Terminator.

How would that look if put into practice?

Like this:

Final Term

And, as you can see, that's exactly what is implemented in Final Term as of right now :)

The flexibility of this approach is boundless: Any arrangement of tabs and split views you can draw on paper can be realized with a few mouse clicks. At the same time, it is completely intuitive and (unlike similar view systems found in popular IDEs) blazingly fast, relying only on standard Gtk widgets.

Speaking of which, and this is for the developers, I'd like to present a little more detail on how this was done and how you can do the same in your application with the greatest of ease.


NestingContainer for the Win

As hinted before, NestingContainer is a new Gtk widget created for the express purpose of enabling the tabbed/split multi-view seen in the above screencast.

While so far only included in Final Term, it is completely generic and agnostic to the type of child widget it contains. All that is required to build, say, a text editor providing the same flexibility with its editor panes as Final Term does with its terminals (gedit tries to do some of that with its "Tab Groups", but is not nearly as flexible) is for the child widget's class to implement the following interface (described here using Vala):

public interface NestingContainerChild : Gtk.Widget {

        // The widget can use this property to indicate
        // whether it is in an "active" state or not
        // (interpretation of that state is up to the widget).
        // NestingContainer ensures that at most one
        // of its descendants is active at any given time.
        public abstract bool is_active { get; set; }

        // The widget can use this property to control the text
        // that is used to label the tab containing it
        public abstract string title { get; set; }

        // The widget can use this signal to be split
        // into two widgets of the same type
        public signal void split(Gtk.Orientation orientation);

        // The widget can use this signal to add a tab
        // containing a widget of the same type
        public signal void add_tab();

        // The widget can use this signal to remove itself
        // from the container. It will also be emitted
        // when the user clicks the close button of a tab
        // that contains the widget.
        public signal void close();

}

The comments basically say it all; once your widget (which can be a simple subclass of a standard Gtk widget such as GtkTextView) implements that interface, you only need to pass a function that returns a new instance of your widget to the NestingContainer constructor and you're done!

Splitting and tabbing can now be controlled from within the widget (e.g. by use of a widget context menu as in Final Term). The widget basically tells the container what to do and the container takes care of all the complexity, including creating new widgets as required. A proof-of-concept text editor using NestingContainer could be less than 100 lines of code and yet provide the user with possibilities not even found in Sublime Text. All the while, the full, stand-alone source code for NestingContainer is less than 400 lines itself (and of course GPL-licensed like the rest of Final Term)! The power of recursion makes it possible.

As you may have guessed by now, I believe that NestingContainer might be of use outside of Final Term as well. If you are developing a Gtk application and would like to integrate multiple views using NestingContainer, I politely request that you contact me at pew at worldwidemann.com so we can do this the right way (i.e. move NestingContainer to a separate library, add any missing features required for full generality, document it, generate bindings etc., then link both Final Term and your application to that library in order to avoid code duplication).


That's the story for today. There have been other changes as well, some pretty important (terminal emulation mostly); for those, I am referring you to the commit log.


Note: As usual, please remember that Final Term is NOT stable yet, NOT feature complete and therefore NOT READY for production use. In particular, although the new tabbed/split terminals feature is certainly very powerful already, it has not been extensively tested and is expected to contain bugs, reports of which are greatly appreciated on GitHub.

Sunday, September 22, 2013

Becoming Big

The three months (sorry!) since the last blog post saw a great number of positive developments for the Final Term project which I would like to write about today.

We're Famous!

On July 8th, following this Hacker News posting, Final Term was the #1 trending repository on GitHub (and remained in the trending repos for several days afterwards):


It has since gone on to collect more than 2.500 stars, making it – unless I'm very much mistaken – the single most popular Desktop Linux project on GitHub. It also appears to have more stars than all other Vala projects combined! It simply blows my mind every time I think about it. To everyone who helped make Final Term popular – thank you!

Shortly afterwards, none less than Bruce Byfield contacted me with an interview request(!) and an article based on that interview has since been published online at Linux Pro Magazine.

I'm trying hard to make the project justify the hype it is generating, which is the main reason there has been no blog post in such a long time, because while there was silence on the blog front, development has been buzzing with activity:

Mac OS X Support

For all friends of the stylish *nix flavor, Keith Layne is porting Final Term to Mac! Fueled by the surge in interest on GitHub, this request materialized within hours and is already being actively worked on. Thank you, Keith!


Performance Breakthrough

Many of the "improvements" made in the past months have slowed down Final Term, and two weeks ago, it at last became clear to me that development of terminal functionality could not continue in earnest without fixing the performance first.

As a result, a number of changes were made to bring Final Term up to speed. It is now "only" 8-10 times slower than GNOME Terminal, which isn't anything to write home about but might be excused given that Final Term manages a much more complex model of the terminal output. In practice, the difference should be hardly noticeable.

Once the remaining problem, absurdly high CPU usage when idle, is fixed (which you can help with by answering https://mail.gnome.org/archives/clutter-list/2013-September/msg00010.html!), Final Term's performance will be ready for the initial release.

Build System Improvements

Two contributors stood out in the past months by their sheer volume of useful work: Dominique Lasserre (whom you should know from the previous post) and Ferenc Erki. Among many other contributions, they have continued to work on the CMake-based build system, cleaning up things, fixing problems and simplifying (please refer to the commit history for details).

Gentoo Packaging

A live ebuild for Final Term is now available in Gentoo's Sunrise overlay courtesy of Ferenc Erki. You can find usage instructions here.

Other Major and Minor Things

As usual, that's not nearly all:


That's it for today, but expect more updates and changes to happen soon. The Final Term project is very much alive!

Saturday, June 15, 2013

We the PPA

With recent exciting developments, installing Final Term has become easier than ever (at least if you are using Ubuntu):

Bob Mottram has packaged Final Term and GitHub user versable built on his work to create a PPA for Final Term on Launchpad. The archive automatically synchronizes with the central GitHub repository to always deliver the very latest version of Final Term with a few hours delay at most.

Thanks to this amazing contribution, from now on, getting Final Term on Ubuntu is as simple as executing
sudo add-apt-repository ppa:finalterm/daily
sudo apt-get update
sudo apt-get install finalterm
in a terminal – and it always stays up to date!


But that's not nearly all...

Two additional improvements have landed in the past weeks:

.desktop and .gschema.xml Localization

Another valuable contribution by Dominique Lasserre, this commit extends Final Term's localization capabilities to desktop integration and GSettings. As soon as .ftmenu files are taken care of as well, Final Term will be 100% localizable!

Improvements to Terminal Functionality

At last, work on advancing xterm compatibility has started in earnest. As a result, you will find that standard shortcuts like Ctrl+C (interrupt command) and Ctrl+L (clear) now work. The behavior of line editing has also been improved, which should result in a slightly better overall experience already.


No screenshot this time?

While there is little to see from the last weeks' updates, there sure is a lot to feel. I encourage you to take Final Term for (another) spin and see how positively the recent work impacts usability. The project is moving steadily towards its goal of becoming a full-featured terminal emulator ready for everyday usage. As always, feedback and other contributions are very welcome on Final Term's development hub, its GitHub page!


Please note that these improvements by no means indicate that Final Term is already stable. Heavy development is still ongoing. Final Term is NOT READY for production use!

Sunday, May 26, 2013

Progress and Plans

Again a week has passed since the last development post, and with the help of a growing community of contributors, Final Term continues to leap forward.

Here are this week's highlights:

Settings GUI

The single most requested feature from the survey has already been implemented only a few days after the survey was launched, courtesy once again of the amazing Tom Beckmann.


Shortly afterwards, I decided to make some long-overdue changes to the settings system, cleaning up things considerably, and to move the fonts from the theme to the settings, resulting in the dialog you see above. Now it's easy to see the terminal output gloriously rendered in your favorite fonts (if you're not using it already, I strongly recommend Inconsolata).
A side effect of this overhaul is reduced performance, because every piece of the UI now reacts to every single settings change. This is easy to fix and will be fixed in the coming weeks; soon, Final Term will be more snappy than ever!

Localization

Fans of non-English language Linux environments will be happy to hear that another of Final Term's priority bugs has been (almost completely) fixed, this time by new contributor Dominique Lasserre: Final Term now has a localization framework, and in fact I already used it to translate the UI to my native German:


Almost everything is already translatable, with the exception of text menus, desktop entry and GSettings descriptions, and those items should follow soon, as discussed here.
Thank you, Dominique! Translations using the standard .pot/.po mechanism are now welcome on GitHub.

What's Next?

I consider Final Term's feature set to now be almost complete with respect to what I want to see in version 1.0, Final Term's upcoming, initial packaged release. Besides the obviously missing stability fixes and terminal functionality improvements, my aim is to get the following other things ready before I'll push to get Final Term shipped in the repositories of all major distributions (and eventually, maybe even as the default terminal in some):

  • Multiple terminals per window using tabs (which seems to be the method preferred by the majority of people according to the survey)
  • Key bindings GUI
  • Maybe: Non-semantic support for shells besides bash (should in principle work already)
  • Maybe: True plugin system allowing management and sharing of termlets, text menus, color schemes and themes

The difficult task of developing terminal functionality lies ahead now. As always, any support is welcome. It is also never too late to take the Final Term Community Survey and make your voice heard in Final Term's development department!

Saturday, May 18, 2013

One Week Later

In the seven days since Final Term's first public announcement, there has been progress in almost all areas of the project, fueled by some amazing community contributions.

That's right. Final Term is now a community project, and given its young age, a very active one. No less than four people besides myself have already contributed to Final Term!

And did I mention that Final Term has in just seven days become by far the most popular Vala project on GitHub (out of over 200 Vala projects in total)?

None of these things would have been possible without the community that is now awaiting the first stable release of what on Twitter has been called


I am honored and highly motivated by such flattery :)


But what actually happened during this week, and who is responsible for it?


Tom Beckmann deserves a category of his own. In just seven days, he:
Desktop notifications on command completion

Progress bars in Unity launcher
  • Fixed several other issues
Thank you, Tom! I sincerely hope you will become a regular contributor.


Jóhann B. Guðmundsson has provided a Fedora SRPM for Final Term here (and one for keybinder here). These can greatly accelerate getting Final Term installed, but please understand that those packages are not official and if you want the latest version I recommend you install from GitHub.


Arch user kens has created an Arch Linux AUR for Final Term. It seems to have worked well for many users, but of course, the same advice also applies for this one.


GitHub user varemenos has announced his intention to create additional themes for Final Term. I am really looking forward to that!


My gratitude also goes to all those that have reported issues on GitHub. Without their feedback, Final Term could not move forward.


My own efforts this week have been focused on stabilizing the program by fixing minor bugs and interacting with the community. I did manage to push one big thing through myself though:

The way termlets (the little helper programs that embed contextual information in terminal output so that Final Term can identify files, folders, PIDs etc.) transmit information to Final Term has been completely overhauled. Termlets can now pass arbitrarily many string variables to Final Term rather than just numerical ones like before. In practice, this means that for example, a description of the operation being executed can be added to the progress bar, which is already implemented for wget:

Progress label describing which file is getting downloaded by wget

This change allows for termlets that would have been impossible with the previous approach. I intend to post a tutorial on how to make a simple termlet on this blog soon.


That is it for now; I'll be back on this blog within a few days and hope the coming week will be as awesome as the past one!


Meanwhile, if you haven't done so already, please take the Final Term Community Survey to make your voice heard in Final Term's development department!