BaulkTerm

Features:

• Real transparency
• Unfocus fade
• 256 colours
• Utf-8
• XML Configuration file
• Can potentially have every feature of Konsole, but without any KDE4 dependencies (except for Qt4)
• Defaults that don't suck

Upcoming Features:

• Faster, less ugly window resizing
• Right click, "simple" configuration menu, think Sakura terminal
• Custom configuration dialog (primarily for Baulk)
• Command-Line options (all options will be configurable from the command-line
• Terminal title, think urxvt
• New-line wrapping on resizing
• Tabs
• Hotkeys will be mappable to any option

Background:

BaulkTerm evolved out of the need for a terminal in Baulk. Initially I had been using an XEmbed wrapper around xterm but was having major issues with focus control. A few months later I had found a wonderful project called QTermWidget. QTermWidget is essentially Konsole (KDE4) rewritten in Qt4 so that there are no dependencies on KDE and prepared as a QWidget. This made QTermWidget very easy to integrate into Baulk (at that time QuillTex). After a few months I decided to completely rewrite QuillTex again (for the fourth time), and I decided to fork QTermWidget for my own uses.

The reasons behind my forking of QTermWidget are simple:

• Bugs in QTermWidget that I want fixed
• Very low update rate for QTermWidget
• I want alot more handles for features available in Konsole than QTermWidget currently provides
• Make QTermWidget fast, which could possibly mean removing/changing features found in QTermWidget and Konsole

Now my principle goal of BaulkTerm is to become my new terminal (I already use it as my default terminal in awesome wm). I am also very open to random terminal features that people may want.

Cool Features that HaaTa wants

• OpenGL, because its really fast
• OpenGL, why else did HaaTa buy a 4870 but for an OpenGL terminal
• OpenGL, because there is no up-to-date usuable full OpenGL terminals (that HaaTa can find)
• OpenGL, because HaaTa hates vim lag

* BaulkTerm requires X11 (Linux, Cygwin, etc.)

* Real transparency requires a compositing window manager

History

Pre-QuillTex

This whole debacle (known as Baulk/QuillTex) started when HaaTa (Jacob Alexander) decided to learn Qt4. During the Summer of 2007, HaaTa was going to a karate seminar in Barrie Ontario (HaaTa is a University of Waterloo student in Computer Engineering). It just so happened that some of the other people in the van (method of travel to Barrie) wanted some of those overpriced coffee things from Starbucks, and that Starbucks had the overpriced bookstore, Chapters. Anyways, HaaTa wanted some reading material for the trip there. So HaaTa went over to the programming section to see if there were any interesting languages to pick up books on. That's when "C++ GUI Programming with Qt4" caught HaaTa's eye.

HaaTa had been using Linux for the last year (Fedora) with his preferred environment being KDE. Mind you HaaTa had already had his intro with Tiling Window Managers at this point with DWM and WMII on DSL (Damn Small Linux). Not to ramble to far, HaaTa bought the book, and learned Qt4 (which helped in getting him his first Linux job at Xandros).

During the same term HaaTa started to use Latex extensively for note-taking. Mind you, this can leave some things to be desired, like diagrams, which is why HaaTa bought a Wacom tablet.

At this point HaaTa's environment was a 15.4" laptop running Fedora (KDE), using Kile and a simple drawing program for diagrams. This was sufficient, but left something to be desired.

This is when HaaTa decided he wanted to do some Open-Source work. After a lot of thinking, he settled on a Qt4 Latex IDE with Wacom tablet integration.

QFS 1 (QuillTex from Scratch)

Not a lot of usable code came out of this version that officially started on August 10th 2007. HaaTa did start to learn about SVN, Sourceforge, and some of the inner workings of Qt4 though.

From the period of September to December 2007 development more or less stopped. This wasn't planned, HaaTa just got his first computer in 2 years that could play games (lots of catching up to do). There were also a bunch of annoying issues with the computer he built (which never fully got resolved till May 2008).

QFS 2

After working at Xandros (Sept-Dec 2007, during the period when the first EeePC came out actually) HaaTa got himself a EeePC 701. One of the first things HaaTa did was get the Wacom tablet working on the 701.

Once getting back to classes in January 2008, HaaTa attempted to use the setup he had been using on his laptop for taking notes on the EeePC 701. Now this works, but you really don't have the screen real-estate for full IDE. So HaaTa became interested in QuillTex again, but this time also focusing on a minimal GUI.

Now HaaTa likes to tinker with OS's alot, so one of the things he made was a custom minimal live cd of Fedora 8 for the EeePC 701 with WMII as the window manager. At this point HaaTa started liking tiling based window managers more and more, as it improves work flow, don't need a mouse, and use very little screen real-estate. Yet, rather than looking to give QuillTex a tiling based control scheme (right away), HaaTa wanted something else. A terminal inside QuillTex.

One of the main features of QFS 2 was that it had an integrated terminal (xterm). Unfortunately this caused so many issues to get working properly with focus (and HaaTa's computer died), that HaaTa put the project aside for a while. (It turned out later, that it would be impossible to get focus support working properly with most terminals (xterm, urxvt) since they steal all keyboard events once they have focus, code changes would be necessary)

QFS 3 (QuillTex || Quintessentially)

After deciding to start QFS, HaaTa found something very useful (May 2008). A terminal written in only QT4, QTermWidget. Now QTermWidget, is Konsole (KDE4) rewritten to only use QT4 by e_k (JK).

For QF3 3 there were actually two distinct versions: List-based Widget tracking (first), and Layout-based Widget tracking.

For the first version basic tiling control was achieved, albeit very very buggy. However, one of the main achievements for the first version was dynamic library loading. This allowed QFS 3 to load Widgets based upon a wrapper function, so one would not have to compile everything together just to use that particular Widget.

Now, HaaTa started to become very productive in the coding since he was now on am 8 month work term. Tiling options such as hiding, resizing, moving, and focus switching were more or less brought up to a usuable state. By this point HaaTa had managed to make a usable product (he was actually using it at work). However, a few big features (and lots of bugs remained).

This is when HaaTa, began trying out plans for a multi-window scheme. The first feature, switching focus control between windows was a success, and worked well. However, the horror that was widget swapping became the largest hurdle for the project (and was never really solved ideally, well till the next year).

Now, the idea was simple. Move one "active" widget (with the state intact) to a different window. By this point navigating around and through all of the dynamic libraries was starting to become painful (since they were an after thought with this revision). The code was only a few lines long, since all you really have to do is pass around a pointer... Now from the introduction so far you'd think it wouldn't work at all. That would be better, since HaaTa would've far less confused.

First when moving widgets would work. Open up two or more windows through QuillTex. Then start up a widget in the first window, and pass it to a window created afterwards. Yes, that's right the widget could only be passed to a window created after the window with the widget. You could not even pass the widget back. It would become segfault happy.

Needless to say HaaTa was very confused at this point. So HaaTa began to look into other means of inter-proces communication.

HaaTa first started looking within Qt for answers but came up to quite a road-block. He was able to send textual and binary data between applications, but not active C++ classes. After trying as many tricks as he could possibly think of, he then started to look at Shared Memory.

For those actually reading this far along, note that Shared Memory is a royal pain in the ass, and should nevert even be considered as an option for what HaaTa wanted to do.

Qt had a class to deal with shared memory, but it was severely lacking, and well didn't really work. HaaTa was able to send super simple data like, an int pointer and such, reliable through shared memory. But something like a generic QWidget derived class, just wasn't happening (segfault city).

The next resort HaaTa turned to was Boost. To make a long story short, this was a complete nightmare. HaaTa was able to manipulate the classes to do shared memory, but ran into problems in key areas.

First he had to instanciate the object in shared memory, ok he did that. But also all of the stuff in the class must also be instanciated in shared memory, which you can only do if you've made the class manually do that, not for the generic classes HaaTa wanted to put into shared memory like a QWidget. Next, he found that anything with a virtual function does not play nice with shared memory in C++. As the map of all the virtual functions is created just for that set of functions in the process. As soon as you move it into another process where anything is different, segfault. Looking back this is similar to the problem where HaaTa could only pass widgets forward but not backwards. As the new Windows were identical to the original but changes to the virtual tables on moving the Widgets forward rendered them incompatible with the Window it was initially created in.

HaaTa also read somewhere that sharing classes between processes was designed to be impossible in C++...fun.

Needless to say, HaaTa had exhausted his brain by this point, and got nowhere.

HaaTa needed to give his brain a break, so he started on the most boring piece of software he's ever written, and XML Configuration Library.

Needless to say it was painful to write BaulkXML but HaaTa finished it, since it was quite useful for random configuration options. However, since HaaTa had plenty of brainpower leftover while writing the XML library he started thinking about a re-write, again.

QFS 4 (Baulk | Almost a Window Manager)

At this point HaaTa was being nudged into using some new technologies. Needless to say, it was all Garoth's Fault™ since he was a co-worker of HaaTa's at Xandros for his final 4 months there.

Garoth, convinced HaaTa to switch from WMII to Awesome WM. Which ended up converting HaaTa to Arch Linux from Fedora 8 (9 was out at this point but AMD/ATi was being an arse about releasing updated drivers, so HaaTa really couldn't use 9 for much of anything) because compiling something as bleeding edge as Awesome WM on Fedora 8 was a royal pain in the ass. He also convinced HaaTa to start looking into using Git rather than Subversion, for pretty much everything. Too bad they still used a little bit of CVS at work still (which was a nightmare).

Now by this point HaaTa was ready to do a complete re-write (well except for the XML Library he had just written). But there was a problem, Sourceforge. Sourceforge was starting to become a complete ass at that point, since they were moving datacenters. So, things, like the dynamically updating site were broken, and there was really no way to fix it at that point. Also, Sourceforge was lacking in the all powerful feature known as Git repos.

HaaTa probed Garoth for some decent free Git Repositories for projects. The two he gave him were GitHub and Gitorious. Eventually HaaTa chose Gitorious since he liked the interface more (less cluttered with random stuff). HaaTa had tried to look for a way to replace Sourceforge, but was unsuccessful, since there really wasn't anything that offered free Web-Hosting without ads other than sourceforge for open-source projects.

On a side note HaaTa has an account on GitHub for his various Linux configs. He usually updates them whenever there are a bunch of updates needing to be done to the configs, since he hates losing them during the occasional screw-up.

That was the start of using Gitorious for Baulk development.

Even though quite a bit of code was written for QuillTex, HaaTa wanted to change everything, since the old layout really didn't take into account dynamic libraries. First, HaaTa wrote a simple Message Handler to identify and forward all the console messages internally. Next, HaaTa wrote his build system in CMake since he had been experimenting with it successfully in QuillTex, and of course because it had pretty console output.

Now, the first very useful function HaaTa wrote was the LibraryLoader class for Baulk. The idea behind the LibraryLoader was to remove all of the complexity in loading dynamic libraries, and to have things like symbols dynamically indentified using templates and lists (rather than having to hard code them in like one usually does).

The next application written was the BaulkServer application. The application consisted of the server, the client code, and the packet definition for communcation between the clients and the server.

Next, since there was now runnable code, HaaTa decided make the code Windows compatible.

BaulkWidget and BaulkControl were created as the main pillars of Baulk. BaulkWidget was created as a reimplementation of QWidget, that all main Baulk Widget classes should be derived from, inorder to add additional functionality, such as pass-throughs for message logs. BaulkControl was created as the central point of control for using Baulk, as it handled the Widget order, control, configuration, and hotkeys.

By this point, HaaTa wanted to do some interesting things, so he created some external Widgets for Baulk. The first being the Message Logger, which displayed all of the console message redirected from Baulk into a Window with pretty colour output. The next was a wrapper for QTermWidget. After succeeding in making a template for such Widgets, he decided to test out how easy it was to create widgets, by making a simple web-browser out of QWebKit.

After a good period of solid development, HaaTa was getting frustrated with QTermWidget. So he forked it (see the BaulkTerm tab above for more info).

After adding a few features back into BaulkTerm (QTermWidget) like actually transparency support, and colour configurations. HaaTa decided to add a Daemon feature, that allows for faster startups of terminals and less memory to be used.

During this time of BaulkTerm development, HaaTa adds a load of build options to the CMake build scripts. These options allow for one to be able to build just a single library out of Baulk (and all of the libraries that one depends upon are also built). This was done, so that BaulkTerm could be built easily as a stand-alone binary (as it was more ready for a release than Baulk was). Around this time an Arch AUR script was created for BaulkTerm.

By this point, HaaTa was finishing up at Xandros, going home for Christmas (flying to Southern BC in the Winter sucks, 1.5 hour flights == 13+ hour bus rides), then back to classes. So HaaTa wrapped up development until reading week at the University of Waterloo (Feb 2009).

Now, during reading week, HaaTa began working on the OpenGL renderer for BaulkTerm. He accomplished two things. One, learn how to use OpenGL. Two, create a Qt OpenGL font renderer. However, by the time he finished reading week was over, and he again had to concentrate on his studies.

QFS 5 (Baulk | What!? A scriptable tiling window manager for Windows!)

As can been seen (if you've made it this far), HaaTa likes to change his mind. However, this time it was less, that he didn't like the progess thus far on Baulk. But, that his needs changed, slightly.

HaaTa managed to get himself a co-op job in Ueda Japan (Nagano Prefecture) working for Seiko Epson. Now the kicker was that he'd be using Windows. Sooo, he actually needed a Tiling Window manager concept that would work in Windows, at least to maintain sanity.

After a lot of thought (and research on MSDN), HaaTa found that creating window manager using the current method (encompassing Qt application) wasn't going to work. So HaaTa decided to go right to the bottom of the windowing stacks of X11 and Windows.

The plan HaaTa set out, was to develop an API that would expose only the commands needed for window control from X11 and Windows. This way, all the inconsistancies would be hidden, and HaaTa could write a Window manager quite easily on top of the commands.

In order to start the API, HaaTa needed some reference material to see how to interface with the two windowing systems. Since HaaTa liked the idea of XCB, Awesome WM was a good choice for example code. Finding an example for Windows was slightly more difficult. But HaaTa had time, with almost 2 months between finishing exams and leaving for Japan.

During his side trip to Fort Frances, Ont. HaaTa discovered HashTWM. This was exactly what HaaTa was looking for. A relatively small window manager for Windows, so he could see all the commands needed, and how to use them. It was just a bonus that it was also a Tiling Window Manager.

Right before HaaTa started coding the new API, he had an interesting idea. One of the common themes of tiling window managers is that they are scriptable. But none that HaaTa knew of were for Windows, and definitely not cross-platform.

Mostly due to sheer convenience HaaTa decided on using QtScript, since he was already using Qt, which would also allow the scripter to have full leverage of the Qt code-base as well. QtScript is a form of ECMAScript for those interested.

TODO, HaaTa is currently writing the API.

Miscellaneous Widgets

BaulkStatus

• Basic HTML Formatting
• Supports 4 types of messages (Debug, Warning, Critical, Fatal)

WebBaulk

• Custom Web Browser using QtWebKit
• Tab Support

Road Map

0.2 - [To be decided]

TODO: Release Desirables

0.1 - Initial Release

(Was almost ready, then HaaTa changed his mind)

ETA: When its done

Baulk Features:

• Initial Release
• Linux and Windows Compatibility
• Very basic multi-window support
• XCB Tiling Window Management for X11
• XML Configuration library
• Fully Scriptable using QtScript (ECMAScript)
• Windows Tiling Window Management

BaulkTerm Features:

• Initial Release
• Colour theme support with a usable default
• Configuration menu (right click) and dialog (Baulk)
• Real transparency support and focus fading
• XML Configuration

Check TaskFreak! for things holding back the release.