ascii-d: Development Log
Copy/paste is a must have for any editor. To implement this, the flow would look like this:
For both select/highlight and extracting content, we have the same behavior. We defined a selected
range as a rectangle…
Opened up the project after a long break, all the code seems to started making more sense, lol.
So I think it would be a good idea to dust it off a little bit….
I don’t know why did I wait for so long to implement this.
Before, if the window is closed, the app keeps running. Druid intentionally implements this behavior to support multiple windows applications. ASCII-d is not designed to be a multi-window app so it’s not necessary….
Today I implemented another shape drawing feature, Rectangle Tool (or
RectTool)! Now we can draw boxes everywhere.
Okayyy, I finally make the text editing experience feels better. By changing a lot in the
TextTool. But let’s take a step back and review what was the issue with the initial implementation.
Previously, each line of text is a
TextShape, when the user inserted a text (by clicking on any grid cell), a new
TextShape will be created. All subsequence edits will modify the attached string of that shape. During the rendering phase, the last created
TextShape will get rendered on the screen. Once the user stopped the text edit (by switching to another tool), the current
TextShape will be committed….
It turned out Druid didn’t have built-in support for Image inside a Button, lol, so I need to build a custom
ImageButton widget. Most of the implementations are copied from the built-in Button widget.
Well, it almost took me a month to finish the text edit function. I had to make many underlying changes like rewriting
ShapeList types to manage the interaction between
Shape and the actual list. More on this in ARCHITECT.md.
The idea is, each drawable shape (line, rectangle, arrow,…) will have
its own Tool object, and there is a ToolManager to manage them all, pass
the current mouse input from the grid into the active tool.
The list of the available tools should be fixed and pre-allocated at
compile time. But it can be dynamic too, just not something to worry about
at this moment….
Well, there are a lot going on in this commit. The app now render
things like background grid or other content based on the visible
area only, not the whole canvas.
The second thing is some early PoC for a reusable character layout,
previously, we use grid_text to render the whole data buffer to the
screen, it requires a lot of text layout update, rebuild, clone the
screen buffer into a new string on EVERY FUCKING MOUSE MOVE! With the
new approach, all box drawing characters which will be rendered on the
screen will be pre-built and never be built again during runtime….
Before the current version, I’ve been trying to prototype ASCII-d using different languages/tech stack, one of them is the obvious choice: Electron. Just to get a glimpse of how my idea looks in action.
It’s been a while since my last attempt to start a SaaS, and I’m starting a new project, this time, I’ll be building ASCII-d, a tool for drawing ASCII diagrams.
You can think about it as an alternative of Monodraw — I love it, with the focus for a more minimal UI and support more platforms (Windows, MacOS and Linux)….