Citronote 3 📝✨️ Used AI

I'm making the final push towards ship.

I've almost finished the trailer video, but I forgot some features I needed to show, so I'm having to shoehorn them in.

Right now I'm mainly working on a demo page. Since my project is Windows software, it'll be a sort of landing page with a download button.

I made a mistake in Git and my directory got corrupted, so I'll git clone it again and work in a new directory.
I've also added the editor library I forked for this app and the Hackatime Project, where I was exploring creating an editor, to this SoM project.

I'm currently working on creating a trailer video. I thought it would be cool to have a trailer.
Suno.ai generated a song that I thought would be a great fit, even better than I expected, so I'll use that song. It's not for commercial use, so it should be okay.

I'm currently preparing for Ship.

It's now possible to add images using Markdown. A better implementation would require a large amount of replacement, which probably wouldn't be possible in time, so I forked the editor library as a temporary implementation and added the necessary functionality.

I've also fixed some minor issues, such as the feedback URL not working and the UI being fixed in Japanese due to lack of localization. I've also created a feedback form.

Im currently preparing for the beta release.
In a previous Devlog, I mentioned trying out Tauri, but it turned out to be difficult, so I went with Electron instead. (I’m aware that some people don’t prefer Electron apps, so Tauri will remain part of the future vision.)
Most of the Electron app implementation was copied from the previous codebase.

Additionally, I added desktop-specific implementations for the React app, the core logic package, and the built-in features package.
For example:

• Desktop-specific implementation of the file system provider
• Desktop-specific implementation of the notebook manager
• Handling parts that didn’t exist in the desktop version

I also worked on other features, such as:

• Adding a beta warning to the notebook list
• Hiding/deleting/handling many features that are postponed for now
• Previously, the title bar icons used <img />; I replaced them with a React component using SVG to allow color changes according to the theme
• Standardizing the header button components
• Disabled an unnecessary focus outline in the plain text editor
• Adding the notebook deletion feature (WIP)
• Adjusting the light theme (WIP)
• Various minor tweaks for the initial ship
• And more… I might have forgotten some things.

A problem I ran into today: after building the desktop version, the exe tries to load the app’s HTML, but:

• It’s loading files that aren’t referenced in the codebase
• Access is denied

I concluded that access was denied because the file didn’t exist in the first place. I also assumed that it was referencing HTML files not in the code because it was falling back due to the original files being missing. I tried many solutions, like correcting the path notation and using different functions.
But none of the solutions worked. I even added logging and window output to debug the file paths being loaded, but nothing was logged at all.

Something seemed off… and indeed, the issue was that the desktop package doesn’t build the source code contents when generating the exe. In other words, although I thought I was changing the process through repeated trial and error, I had actually been inspecting the same generated output all along. WTF

I've completed a rough implementation of the Scrap feature (infinite scrolling and other features are very difficult and time-consuming, so I implemented a rough implementation that rendered everything), made various adjustments, file uploads, and worked on components that had not yet been implemented and parts that I had been putting off.
I'm currently working on a desktop package using Tauri.
Also, I think the vscode source code will be useful for file system abstraction.

• Commit to Git
• Have the current codebase reviewed by AI (Coderabbit) to identify issues and implement fixes (adding type guards, making HTML standard and accessibility improvements, refining state, removing dead code, introducing only-allow rules, cleaning up code, and other fixes etc)
• Separate UI components into a different package so they can be used from plugins or other sources in the future
• Sidebar header (notebook selection) is now functional
• Made adjustments to many parts
• Created state for the folder tree to allow folder creation and deletion (this took a lot of time, and I’m not confident about the state design)
• Working on a new note type called Scrap
• etc.

I can now create folders and notes! (Until now, there actually wasn’t any UI for creating them.)
I tried to make a UI like in VSCode, where nested folders are listed and clicking smoothly turns the folder into an input box. But it turned out to be pretty challenging in terms of both implementation and UI design. In the end, it came out nicely, so I’m glad. (Though some details like existence checks are still missing—I’ll add those later.)

Right now, I’m reviewing and rebuilding the interface of the abstracted file system class.

Also, while talking with ChatGPT, I learned about something called JSDoc. I had thought it was just a relic from the pre-TypeScript era for explicitly stating type information, but being able to write natural language descriptions that show up when hovering over a function is super convenient!
I also want to get better at writing clean, maintainable code, so I bought a book called The Art of Readable Code (Japanese edition). Apparently, it’s quite famous.

Recent progress:

• Refined the editor system. Until now the editor’s width container was implemented by restricting max-width and setting margin-x to auto, but I changed it to use CSS Grid so that the editor component can overflow outside of the container when needed.
• Enabled horizontal scrolling in the plain text editor. For plain text editing, text wrapping alone is sometimes insufficient.
• Previously, the plain text editor had a structure with a Codemirror editor spanning the height of the entire document, but I changed it so that the Codemirror editor’s height matches only the visible area. This enables Codemirror’s virtual scrolling, so it can now handle large amounts of text smoothly.
• With the editor height fixed, the horizontal scrollbar can now be moved without having to scroll all the way to the bottom of the document.
• Started implementing the Markdown editor.
• Using ProseMark as the Markdown editor library, but encountered an issue where formatting syntax such as ** remains visible on the right side after rendering. At first, I thought it was my mistake, but it turned out to be a problem with the library package. I stopped using the npm package and switched to using the latest commit package via pkg.pr.new. Since this library is still in development, issues like this can happen. Until the library has a stable release, I plan to keep following development commits this way.
• Currently, the project has a main page where you can open notebooks and write notes, and a notebook selector for choosing notebooks. Since some of their required init processes differ, I changed it so that they are built as separate HTML files using Vite. In practice, both reference the same HTML in the source code, and the script loaded on that HTML file is swapped out.
• etc.

I have also come up with an idea for another project and feel like working on it too, but since I am not sure if that would make it in time for the Summer of Making deadline, it seems better to stay locked in on this one.

I'm continuing work on the editor! I think the progress is going well :)

Main things I did:

• Various adjustments to the plain text editor using Codemirror (such as styling to push line numbers outside, etc.)
• Created types and extension points for the editor component. This includes React components and information like whether the editor scrolls, or whether the editor component is placed inside a container.
• Tailwind wasn’t working properly because there were two packages storing React components. To fix this, I added @source to the CSS file so that it can read the class names of the referenced package.
• Added extra spacing below the editor, which improved the appearance.

I feel like I’ve built a pretty nice plain text editor! Tackling the important functionality of reading and writing files has made me feel like things have really moved forward.

Also, file saving is now debounced. (This was a behavior I had already decided on a while ago.)

The attached file is from a session a little while back, so things are slightly better now.

Ah!! My Unlogged Time has reached 11 hours!!

What’s worth mentioning about what I’ve done recently is the design of the “note types” and the development and design of their extensibility and various other things.

Specifically, I implemented:

• Added an init function to packages/core. This handles things like registering built-in note types to the notetypeRegistry that manages note types (and in the future, registering plugin note types as well).
• Added necessary functionality to notetypeRegistry, like retrieving a note type from a file extension.
• Created an icon object and a component to load custom icons (not from lucide-react) so that icons can be easily added or loaded from plugins or extension points.
• Updated note types so that each note type can have a different editor component.
• Built-in note types were previously in packages/core, but since note types now include editor components, they require a React dependency. I didn’t feel it was right for packages/core to depend on React, so I created packages/builtin and moved them there. (In hindsight, maybe it would have been fine to just keep them in core…)
• The editor pane in packages/app now loads the editor component from the note type.
• The folder feature I mentioned in the previous Devlog is now complete! It works stably.
• There are probably other small changes I’ve forgotten…

Since app components might need to be used by built-ins or plugins, we may need to add packages/ui.

I had planned to implement plugin functionality, but it seems difficult, so for now I’m focusing only on creating a codebase that will make implementing plugins easier in the future. Plugin functionality will come after the MVP ship.

Also, I’ve been developing somewhat aimlessly, and surface-level progress hasn’t been much… I usually set “daily work hours” as my goal, but maybe it would be better to set goals like “features to implement today.” Also, development and design might need to be more agile… :thinking: (The biggest reason development is slow is that I’m completely inexperienced with large-scale development. My brain’s RAM is slow :( I want to upgrade to DDR5.)

I also need to increase the frequency of Devlogs. If I get lazy and don’t write Devlogs, I forget the details of my development. Honestly, part of me likes saving things up and dumping them all at once, but if I forget details or accidentally go over 10 hours, that defeats the purpose. So I’ll post Devlogs more frequently from now on. Also, Devlogs don’t need to be ridiculously long blog-post-length entries; they can be short, like commit messages.

Aside:
I’m an individual developer, providing non-physical data to the world via the internet and other channels, but I have a fascination with shipping actual physical products.
I’m thinking that if this project gains some recognition, I’d like to create a merch store. Specifically, I’ve made an on-demand store before where you just upload images to create a store, but what I want is to actually hold inventory, ship items myself, and sell things I’ve designed from scratch, not just items with a logo. Doesn’t that sound fun?

I’ve been researching and discussing with ChatGPT, and today I properly learned the concept of OEM. The idea is to design and conceptualize products and then have a manufacturing company produce them. Of course, it will probably be expensive, but I want to do it someday.

…Daydreaming about this is fun, but what I can actually do now is type code and bring it to completion… development is patience.

In the previous Devlog, I was laying the foundation for packages/core (shared logic), but now I’ve mainly started working on packages/app (the React app package).
Right now, I’m focusing on implementing “folders” in packages/app. Folders can now be displayed in the tree. You can’t create new folders yet, but that’s only because I haven’t made a proper UI/component for it—the underlying mechanism for creating folders is already in place.

✅ Migrated components and files into packages/app that can be reused as-is from the previous codebase
✅ Improved handling of “folders”
✅ Display folders in the sidebar tree
✅ Previously, the old codebase loaded all folders at once, but now they’re only loaded when expanded
✅ Updated the sidebar tab system to make it easier to extend in the future
✅ 404 page
✅ Handling for browsers that don’t support required Web APIs, plus related component updates
✅ Minimal PWA (WIP)
✅ And more...

Also, I mentioned before that I would rebuild the codebase from scratch, but for packages/app I’ve carried over a lot from the previous codebase.

Because I was unfamiliar with large-scale development, my code base had become a mess after numerous specification changes.

I lost hope in the current code base, which was riddled with technical debt, so I created a new code base.

I also created a new Git repository.

Oh no, my unlogged time exceeded 10 hours...
This time, I worked on the core design again. It took a lot of trial and error, but I've pretty much nailed down the design. Or rather, I've decided on it.

Things I've tried over the past while:
* How should I import/export packages/core when using it from packages/app? (Consolidate it in index.ts / Barrel export, etc.)
* Should core be an init function + a fairly independent singleton class file? Or should I create a class called Core and consolidate everything there? (In that case, packages/app does not import anything other than the Core class.)
* After much deliberation, I looked into the source code of the OSS I use and found that it uses something called a DI Library. Using this as a reference, I tried out TSyringe.
* I consulted ChatGPT extensively about the specifications until I hit the daily limit.
* And various other things...

In the end, for now,
* I barrel export separate files like initCore and NotebookManager, and use each one in the app.
* Each class file is a singleton.
* TSyringe doesn't seem necessary yet in this design, so I've removed it for now.

So, I'm moving forward with this. If there are no particular problems, I'll leave it as is.

Im rethinking the design.

Currently, Citronote uses a monorepo structure, with the following packages planned:

• packages/core – Contains core functionality and logic, used by both the app and mobile. User plugins generally interact with this.
• packages/app – The React app for desktop and web.
• packages/mobile (planned) – The mobile app using Expo (React Native).
• packages/electron – The desktop app that wraps the app with Electron.

At the moment, some logic still exists inside app, and the export approach from core is temporary. However, as I work on implementing the concept of note types, I've decided to improve the design of core.

Specifically, with the current design, the app’s note types would end up being hardcoded. But since I want users to be able to add note types via plugins in the future, I’ve decided to both redesign core and implement this with extensibility in mind.

Also, with this redesign, the app's features won’t be so tightly bound to the app itself - they'll be more flexible. That means it'll be easier to implement user plugin functionality, which is great! Before, I felt like I don’t know how to make extension points for plugins, it seems difficult, but now it feels like it might be possible.

I’ve been working on an editor pane that includes a Markdown editor, a plain text editor, and an image viewer. In the end, I decided to go with a Markdown editor library called ProseMark. It’s still under development, but I really like where it’s heading, so I wanted to give it a try.

Figuring out how to build the Markdown editor itself took me a long time.
In a note-taking app I made before, I used a library called EasyMDE, which is a fork of the well-known SimpleMDE editor. But honestly, I wasn’t too happy with how it worked. EasyMDE makes you switch between the raw editor and the rendered preview, and while that’s fine, I’ve always admired the smooth WYSIWYG style of editors like Typora or Obsidian.

So I went hunting for a proper WYSIWYG Markdown editor library. The first round of research didn’t turn up anything great.

At that point, I thought I’d just build one myself. I tried hacking around with an HTML contentEditable element to hide and show Markdown syntax depending on the cursor position. That turned out to be harder than I expected, so I gave up. My next attempt was to build it with Codemirror. There are some examples of Markdown editors using Codemirror v5, but the current major version is v6, which has a completely different API. This attempt went better than the first one, but it was still tough, and in the end I started looking for existing libraries again.

That’s when I discovered a library called HyperMD, which looked like a perfect fit for what I wanted. It worked really well, but then I noticed the last commit was seven years ago. It’s built on Codemirror v5 too, which doesn’t help.

I wondered if anyone had forked HyperMD and kept it alive. That search led me to ProseMark, which is basically a fresh take on HyperMD built on Codemirror v6. It’s still in development, so some features are missing and parts of the UX feel a little rough, but I see a lot of potential in it, so I decided to adopt it.

What’s cool is that ProseMark is basically doing what I once tried (and failed) to do - building a WYSIWYG Markdown editor on Codemirror v6. I really respect that, and if I get some free time, I’d love to contribute to the project.

✨️ The page for creating notebooks is (almost) complete.
✨️ I created a menu for clicking on a notebook.
✨️ I added the exists function and the ability to load binary files to the abstracted Filesystem class.
✨️ You can now add icons to notebooks.
🔷 I've made progress on developing a theme cache for the background during startup.
🔷 The focus ring style has been improved.
🔷 Some components have been standardized.
🔷 I've added a Zustand store for storing classes for currently open notebooks.
🚧 I'm working on PWA support.
💩 I was trying to implement a mechanism for opening popovers from tab components, but I couldn't figure it out, so I put it off.
🩹 I fixed an issue where elements would overflow and not fit on a single screen.
and more...

I haven't been able to work much lately, so I think I should take a little more time.

I’ve been hopping around and digging into different features.

I made a Git repo earlier, but since I didn’t really plan things out and just kept jumping between features, I’ll probably end up with an all-in-one commit that bundles all my recent work. If this were a production team project and I were the reviewer, I’d definitely be confused - but since it’s just me, it’s fine.

I don’t really remember everything I worked on, but looking at the git diff jogged my memory:

• ✅ Tweaked the handling for notes, notebooks, and folders I built before
• ✅ Added a “...” button to the sidebar—just the UI for now, but it could be useful for future plugin extensions
• 🚧 Started reworking the onboarding page. Halfway through I realized I needed a slide animation system, so I built one
• 🚧 Working on a UI for creating notebooks inside the notebook selector window—also uses the slide animation system
• 🚧 Building a new input box component
• ✅ Customized the scrollbar style since the default one clashed with the app’s vibe
• 🚧 Working on theme caching so the app doesn’t flicker on startup
• ✅️ We created the concept of the active notebook
• etc

Oh, and Hackatime says I’ve passed 100 total hours (across all projects). I’m calculating how much more work I need to do to get the prize I’m aiming for. Sadly, my summer vacation is almost over, so I’m not sure how much time I’ll actually have 😭 and what about homework?

As for what I can actually show in the attachment… I built a page component with horizontal slide animations. It looks simple, but things like easing and timing turned out to be trickier than expected. Switching from ease-out to ease-in-out made it look way better, which surprised me. (I took inspiration from GNOME and similar systems for the feel.)

I’ve been working on the note handles, revisiting the class design and such, and now the desktop version can also load notes :) It’s coming along nicely.

Also, I think the UI for the note list has gotten a bit better.

It’s still a long way from being finished, but I’d like to have a minimal MVP ready by the end of September. (I believe it’ll probably be extended until 9/30, but this island isn’t going to sink away before then, right!?)

Working on handle note/files.
I feel like the UI for the note list is a bit off 😭

Now can handle and display folders.
I also worked on context menus (WIP), theme support (WIP), and other miscellaneous tasks.
Also, I wrote before that I used Biome, but it was difficult, so I changed it to Prettier.

First Commit 🎉🎉🎉🎉🎉

🎉 I finally initialized a Git repo. And… this is where the story begins…! (yeah kinda late lol)

So, I’ve been dealing with some random little chores. Went through the file directories, tidied things up, deleted files I made during trial-and-error but don’t use anymore, and also got rid of empty folders.

Also I addd Biome for code formatting. Prettier is the famous one, of course, but i thought trying something new sounded cooler, so I went with Biome. Figuring out how to ignore files and folders was way harder than I expected (ChatGPT kept suggesting config files that don’t even exist :( )

And yup, finally made the Git repo. I posted on my Devlog a while back like “It may be time to init Git 🤔” and… it’s been two months…
I also got a bit stuck thinking about branch strategy. i usually go with Git Flow when I’m expecting the project to be kinda big, but there are a lot of people online who say Git Flow is bad, so I hesitated. In the end, I figured I can always change things later if stuff breaks, so I went ahead with Git Flow for now.

P.S. I found a Wikipedia article called “Analysis paralysis”… and wow, that’s totally me 🤦
https://en.wikipedia.org/wiki/Analysis_paralysis

Implemeting theme feature. I briefly considered trying Emotion, but ended up going back to Tailwind.

Part of the mechanism for managing and loading notebooks
(Im currently working on changing the theme to change my mood)

Object-Oriented Notebooks :)

Organizing the core logic into packages/core, changing the infrastructure (yet again)...

Working on a persistent store, a notebook infrastructure, and more

Tooltip!

I'm working on the notebook selector screen. I think the UI is pretty good.

I was pressured by explorpheus on Slack to post a Devlog, so here it is. — I guess I should post more frequently.

Well, recently I’ve been focusing on building the foundation of the project. Also, in the previous Devlog, I said I introduced Redux Toolkit, but I actually switched to Zustand.

-< Abstraction of Notebooks >-
First, this software plans to support two locations to store notes:

• Local: The “folder” on the PC itself acts as a “notebook.”
• Cloud: Notebooks are managed on a server (I’m not developing this now, but it’s part of the future vision, so I’m building the foundation early to make it easier to implement later).

Furthermore, this project is planned to support two platforms: browser and desktop (using Electron).
Here’s the problem: for the local storage, the way to manipulate the file system differs between browser and desktop. The browser uses the File System Access API, while the desktop version uses Node’s fs module via ipc.
To handle this efficiently and maintainably, it’s necessary to abstract away the differences between platforms and storage locations inside the app. This time, since there are two layers — platform and storage location on top of that — it was quite difficult. But I think it was a good learning experience for large-scale development.

-< Window Issue >-
Let’s consider the difference between a “native app” and an “Electron app.”
While it’s good to unify languages and platforms technically, what I thought from a UI/UX perspective is that Electron apps basically run on a single window and rarely use multiple windows.
For example, the software I use called “YukkuriMovieMaker” is made with .NET, so I think it’s a native app. It has windows like:

• “Settings”
• “About YukkuriMovieMaker”

These are implemented as separate windows, which is common. Electron apps tend to use modals layered over a single window instead.
Windows UI itself rarely layers things inside a single window; rather, it uses multiple windows for that.

I think this is because Electron is a framework to build desktop apps with web technologies, and the general web app principle is “one tab = one app session.” I’ve never seen a web app that opens multiple windows.
Also, many Electron apps are basically wrapped web apps originally made for browsers (e.g., Slack).

(I was thinking about this difference when comparing GDLauncher and MultiMC in the past.)

So, simply put, which do you think is more convenient: “multiple windows” or “one window with modals”?
I think multiple windows are more convenient. From a user’s perspective, it might be easier to rely on the OS’s native window features.

However, my app has both desktop and web versions. Since browsers cannot open new windows like desktops, it might be better to use windows on desktop and modals on browser accordingly.

That said, as I mentioned, web apps generally treat one tab as one session. In Electron, each window is a BrowserWindow that opens a specified URL and is equivalent to a tab.
Windows behave like separate tabs, so their state (like Zustand state or variables) are isolated and separate. The only way they can communicate is via ipc through the main process.
Writing this out, supporting multiple windows is really tough. It’s easier if the app’s core logic is in the main process, but since this app also supports the web app version, core features must live in the React app.

Anyway, unrelated to that, I recently needed to create a selection window separate from the main window, so I worked on the mechanism for that. While building it, I was also thinking about making it flexible enough to support the above window usage.

Honestly, I feel like I’ve spent too much time on design and not enough on coding this time, so I temporarily set that aside and created the mechanism for a “window that selects which main window to call.” (What was all that text before for???)

Oh, I’m still undecided on some things and don’t know how it will turn out.

-< So what did I actually do during this time? -->
Since I was lazy and didn’t initialize a Git repo, some things might be missing, but...

• Switched from Redux Toolkit to Zustand
• Used a provider-based design to abstract storage of notebooks and notebook lists (IndexedDB in browser, JSON files under appdata on desktop)
• Tried structuring code under a features/ directory
• Created a page/window for the notebook list menu
• Improved the desktop package’s support for multiple windows and organized the directory structure
• And more...

I doubt many people actually read Devlogs, but somehow I ended up writing a really long text. Probably it’s better to post short updates more frequently. The window issue and other topics might be interesting enough to write separately on a blog or something.

I did various things, such as introducing Redux Toolkit for state management, creating an electron package in a monorepo, migrating to pnpm, and trying out electron-builder.
This time, I've attached the current state of the installer.

Trying out Aptabase

Oh I almost forgot to record it...
I'm experimenting with the note component. It's hard to make the UI look good.

Building Theme Selection (Onboarding)

wip - It's hard to make it look good

I'm trying to build an onboarding screen. This is an mockup I made in Figma quite some time ago, but I'll probably change it.

I needed a separate page for onboarding and other things, so I installed react-router-dom.
I also experimented a bit with styling and design (like how to handle the root folder in the UI).

Optimized the process a little
(It may be time to init Git🤔)

The banner has been set!
I also organized the code a bit by componentizing it a bit.

Package/Repo configuration plan...

Tabs!

I created a folder collapsing UI. I love how it works and how it looks :)

P.S. I want to publish an app on Google Play, but it seems that people under 18 can't register, so I'm having trouble :(
If anyone has managed to achieve this in some way, please let me know how you did it!

I'm currently thinking about and putting together the technical specifications for the project.

I have also started developing the UI, including the button and folder selection components, as well as the rough layout of the overall UI.