Zig IDE: Devlog #03
This month was a doozy! I had hardware problems and other difficulties that ate up a lot of my bandwidth.
Rather than dwell on a disappointing month, I want to move forward and focus on the next month. That means I'm rushing this devlog, but it's for the best!
Disk Failure (not IDE related)
On the first day of WWDC I went to install the macOS beta to try out all the new SwiftUI stuff, and found out that my main drive was failing when the macOS installer refused to do any installs.
This ended up being a huge pain. The process of starting a warranty claim, backing everything up, and configuring a new macOS install was rough. It ate up close to a week of my time.
Thankfully I didn't lose any data, and the manufacturer sent me a new drive. And while the timing could have been better, it does feel good to be working on a fresh install with no clutter.
WWDC 2022: Apple Giveth
WWDC brought a lot of useful updates to Swift/Swift UI that will help me complete the IDE. Some specific cases where I think an issue I had was addressed:
- Welcome Window (I made use of the new Grid layout component to get it to its current state, which you'll see below)
- Navigation for the Zig Language Reference and Autodocs (a new Navigation/deep linking system should prove useful)
- Rendering code screenshots (ImageRenderer)
- Support for Sliders with custom fills? (I have been using a custom slider control, but am afraid to keep extending it since it's quite a bit of work to maintain. I think Gauge might let me only maintain my customization, and leave the gestures, etc. to Apple.)
- SplitViews (I've been hoping they would allow more customizations. Instead a really powerful Layout container was added. This means I'll be writing a custom SplitView, but it should work much better than my previous attempt).
- Charts (I haven't shared my plans yet, but I have some sketches I'm excited to build out as actual UI and show off in the coming months.)
What didn't change
I have been stalling on a few things out of fear they would make major changes. Those include:
- Theming
- Persistence/Model Design
Since no major changes came in these areas, I can continue working with the existing APIs.
Learning about Compilers
My progress through Crafting Interpreters was basically non-existent this month. Maybe I'm testing out the spacing effect?
Seriously though, I'm disappointed and will get back to reading it next month.
Designing the Welcome Screen
The welcome/splash screen is one of those things that I'll always remember from being a teenage computer nerd. It seemed like I was always waiting on these two:
Fortunately, computers are fast now, and splash screens are no longer necessary, right?!
We do need a jump-off point for the user though – a way to guide them towards getting started on whatever job they need to do. Most (or every app that I can think of) do this through a Welcome Window. It's the window where you open an existing project or start a new one. Once you make the selection, you are then taken to the actual program to do your work.
Just keep iterating
After thinking about the various tasks I'd want to perform with the IDE, I made the following sketch:
With UI it's easy to underestimate the time it takes to make something nice. When we judge something we have the luxury of being presented with a potential solution, where the developer/designer has already thought through how something should work.
As a developer/designer, it's difficult to start from nothing and imagine how someone will use your program to achieve their goals. That part isn't usually thought of, and for me, it takes a lot of iterations. In between each screenshot, there were probably hundreds of builds, each testing a tweak to the padding, etc. It adds up to a lot of work!
Future Improvements
One change I want to make is to not have a separate window for this Welcome screen. It doesn't seem necessary to me, even though it's a common pattern.
Instead, this "Welcome Window" will just be displayed as the initial state of the main IDE Window, before you've loaded a project. When you select/start a project, the window transforms into the workspace – no new window – one less context switch. Doing it this way will also save me from having a bunch of "No files opened" messages everywhere too.
What's Next?
I want to make some progress in figuring out how the app will save data. I did some research and have decided to go with a proven library for working with SQLite called GRDB. Not using an Apple framework is a little risky, but I think the benefits of GRDB are worth it. And the fact that it's simply SQLite should make the transition to something else in the future easier, should the need arise.
I'm still just beginning to implement GRDB, but so far it's going well. The next thing to move over to GRDB would be the IDE settings. I currently write those out as a JSON file. Getting that all stored in SQLite will be a big step forward.
Following that, I need to decide how IDE "projects" should be saved. There are a lot of directions to go here:
- Store the project config in a file so they can be stored in version control, shared among users, etc.
- Keep the config in the SQLite database
- Store in the database by default, and allow the user to dump the project out to a file so it can be stored in version control?
I'll have to spend some time thinking about the pros/cons of each approach, and what is most important for the IDE.
Metrics
Some useless but fun stats:
- Days since the first commit: 608
- Lines of code: ~28,363 (+5,687)
- Commits: 1,029 (+120)
Notes:
- Many LoC were from the new SVG files for the Welcome Window icons
- FYI: Work hasn't been consistent the entire project duration
Now that WWDC has passed, I feel good about tackling persistence, and the final pieces of the theming implementation. These issues are pretty heavy, and not very visual. Due to that, I may skip the July 2022 devlog if I feel like it'd be beneficial.
Thanks for reading!
-- Austin (twitter)
Tagged Zig IDE , Zig , macOS and devlog
