huy.rocks/ascii-d

ascii-d: Development Log

Feb 23, 2023

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…

Read more ->

Feb 22, 2023

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….

Read more ->

Mar 20, 2022

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….

Read more ->

Dec 22, 2021

Today I implemented another shape drawing feature, Rectangle Tool (or RectTool)! Now we can draw boxes everywhere.

Read more ->

Dec 17, 2021

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….

Read more ->

Dec 14, 2021

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.

Read more ->

Dec 11, 2021

Well, it almost took me a month to finish the text edit function. I had to make many underlying changes like rewriting GridList and ShapeList types to manage the interaction between Tool Shape and the actual list. More on this in ARCHITECT.md.

Read more ->

Nov 2, 2021

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….

Read more ->

Nov 1, 2021

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….

Read more ->

Oct 21, 2021

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.

Read more ->

Oct 10, 2021

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)….

Read more ->