Allen Webster
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!

Allen Webster
Hey folks,

Today I am announcing the first 4coder build to come out of the "Summer of 4coder". This new build is the first to feature the GUI system I have discussed in older blog posts, and now that it is out I will take a little more time to describe some of what I discovered, what I have come up with so far, and what I would like to do even better.

In the mean time if you are supporting the project be sure to go check out the new build!
Allen Webster
One whole month has passed but there has not been a single 4coder update. I was hoping all month that today there would be an update with new GUI stuff ready to go, but it's just not going to happen. The new theme editor is getting there pretty quickly, and there are some other improvements I would like to have in the next version. Specifically I want to address the high idle CPU usage by going to a system that is more event driven.

Now for the good news. With school year over though the way is cleared for an entire summer of 4coder. I have high hopes for huge updates this summer. I plan to open the customization layer up even more. These new upgrades will hopefully facilitate projects like 4coder vim keys (by ChronalDragon) and providing a customizable GUI for various debugger projects that have cropped up. But my biggest goal of the summer is to start cracking the code intelligence that I was imagining when I first started 4coder. I am making no promises but I think there is a lot to look forward to for the next few months.

As always, thanks for following, and thanks to my backers for their patience through this slower month.
See you around everyone!
Allen Webster
So thanks to the works of the Handmade Dev guys, 4coder is going to have a new home right here on handmade.network!

I mean first of all, the projects are all exciting and I just want to be nearby when awesome stuff happens, but also... look at this site I mean for literally no work at all the 4coder blog suddenly looks about a hundred times better than it did back when I was trying to design it myself. Also did you notice how fast everything is? It is off the hook people.

If you want to check out the old blog, if it is still up you can find it here. My plan is to eventually ditch that blog entirely and move all the old posts here. So from now on you can just follow my absurd blog posting here.

Thanks a ton to the handmade dev guys.

Later everyone!
Allen Webster
The following parts of the Software are separately licensed as follows:

- The Liberation font family is licensed under the SIL Open Font License (version 2 onwards).
The full text of this license is available in the accompanying 3rdparty/sil.txt file

- The Hack font family is licensed under the a modified SIL license
The full text of this license is available in the accompanying 3rdparty/hacksil.txt file

- The Inconsolata font family is licensed under the SIL Open Font License
Copyright (c) 2011, Raph Levien ([email protected]), Copyright (c) 2012, Cyreal (cyreal.org)
The full text of this license is available in the accompanying 3rdpart/sil.txt

- The Cutive font family is licensed under the SIL Open Font License
Copyright (c) 2012 by vernon adams ([email protected]:uuid:d6372abd-c1e2-4403-b5fc-8b1bf8ed9582)
The full text of this license is available in the accompanying 3rdpart/sil.txt