4coder's GUI: Problem Statement

The primary goal for the 4.0.x family of 4coder versions is to figure out the actual GUI system that 4coder will use and to give absolute control over the GUI to the custom layer. I want to see users be able to delete the code that adds the scroll bar to the file, or write up a tool bar for functions they would rather not tie to a key-combos, or to create drop down menus for their custom word completing system, or to trivially modify open file and new file to work exactly the way they want. It was the big topic on my mind for about six straight weeks.

Recently, I having been trying to figure out the best way to describe everything I have learned in a blog post, but it just does not boil down to a succinct string of text. So starting this week I will begin writing a blog post every week until I have described every last detail. I hope you are prepared for a long journey to catching up with 4coder GUI, because it's time to begin.

"To solve the problem, you must know the problem." - Certainly someone has said this, perhaps a meditating monk or a curmudgeonly programmer. And I am inclined to agree whoever said it, so let us start with the problem statement!

4coder's biggest asset at the moment is that it is extendable through native code compiled from C++. So the GUI also needs to be fully customizable in the same custom layer. When I say *fully customizable* I do not mean in that way that most programs now have one or more plugin systems available that kind of let you interfere with the built in behavior. I mean that even the default behavior itself is just code written in the custom layer. There are a number of benefits to this policy. First, the more default behavior that is implemented on the custom side, the more powerful the custom API will be for everyone else. Second, if the default behavior is close but not quite right for someone, they can easily tweak it however they want without writing an entirely new customization or hacking it in some other undesirable way. Finally, this means that the default behavior becomes well tested example usage code that I would have to write either way. On top of all that, it should also be very simple for the user to write the GUI controlling code. If customizing the GUI is even a little complex, then probably very little of the rest of the system will even be put to use.

The GUI in 4coder has to be driven by both the keyboard and the mouse. For instance, the arrow navigation of the file list was one of the most highly requested features. On the other hand plenty of other people have expressed concern when a new build happens to break something their mouse use to be able to do, and there are still requests for the mouse-wheel-click to paste thing for Linux. So the GUI system must support customization for both of these devices.

When a user is doing something like search or replace in 4coder a little text bar pops in at the top. I am rather fond of not wasting that screen space all the time, so being able to show and hide the bar dynamically is important. When the bar shows up though, there is usually no need for that to effect the placement of the file on screen. To support this that bar "overlaps" the file.

To support requests for things like drop down menus, or auto complete menus, or pop up lists, the system also needs to be able to arbitrarily place a new layout box anywhere in a panel. This may sound like it should just be an extension of the overlapping text bars, but it turns out that if we dig in we will find some tricky distinctions between them, and not until we dig even further will it be clear what the best way to handle these two is.

Almost every single GUI in 4coder requires the ability to scroll. While this is not perhaps a particularly difficult feature to have on it's own. It turns out that in combination with other requirements on this system, the scrolling system becomes non-trivial. In fact to be entirely honest with you, my readers, even now the scrolling system is the most brittle part of the 4coder GUI system, which suggests there may be something better to do with it that I have not found yet.

Each view should have it's own distinct GUI system. The reason for this requirement is that, as I see it, the other option is to say that there is only one GUI system, and the old idea of panels and views just exists within that. I do not see a lot of benefit to putting that much on the user. In my mind a code editor will pretty much always be something divided into panels for viewing different things at the top level. To avoid all the extra complexity that would go into having the custom layer manage the panels and views themselves, I decided there would be one instance of the GUI system within each view, and that the panel/view system would remain a core property of 4coder.

That is it! Put all those requirements together and that is the entire 4coder GUI problem. Next week I will start pointing out all the tension points I have discovered between these requirements and I will explain what it took to solve each one.

Thanks for following everyone!