Devlog 03

Ok, it’s been so long (school takes up too much time). Despite that time, this is a really short devlog.

Updates

We have a mockup for the UI that we want the app to have. Now, the mockup (since AI made it) focuses a bit too much on just tasks, but the app will be a notes app; just wanted to make sure that was clear. These colors aren’t finalized and neither is the UI, but the design is what we think would work best for our app. The mockup is attached as a picture.

Feedback

If you guys have any feedback on the UI or just features you want to see in the app (description of app is in the first devlog), you guys can post comments here or add a suggestion on Github: https://github.com/get-glide/Glide-Mac/discussions/9.

Thanks for reading and have a great day!

Devlog 02

Still the same basic editor as last time, but we are working on UI design right now. We should have a somewhat decided design in a couple of days.

More parsing stuff

Anyway, I got markdown header formatting working in the app (you can’t notice a difference visually, but the app knows whether you want a # or ## header now). Now, the plan is to work on getting inline formatting to work (bold, italics, etc).

Dates and moving tasks to different days

For being able to have a task repeat weekly, the app needs to be aware of the original day that the task was created on. To do this (as you can see in the image), every task gets a @created(yyyy-mm-dd) tag. The other tag you see in the image (@carried) means that task was procrastinated on and got moved to the next day or postponed to some other time.

Side note

Maybe it’s just me, but the git integration in Xcode is confusing. I may or may not have had to redo some code and that is why this devlog has so much time on it. I’ll make sure that my future devlogs aren’t this unproductive when it comes to actually making features.

Thanks for reading my devlog and have an amazing day!!

Devlog 07

So I might have gotten sidetracked from the settings app cause it’s such a boring app to work on. Instead, I started working on the unit circle/calendar app. I thought it would be a good idea to combine those two to make the calendar app interesting. However, since there are 365 days and only 360 degrees, I’m going to combine 6 days (probably the week of pi day) into one SUPER PI DAY or some other name. To draw the circle, I’m using an HTML canvas element. I’m learning that it’s actually a really cool element, but obviously not as cool as a div element.

Devlog 06

Unfortunately, I couldn’t get the clipboard history to come up in the M+ panel. Instead, I made a system stats counter (image one). I know, it’s not as useful and it has some pretty lame stats right now. I can’t fix the useful part, but I will try to make the stats more fun/interesting by the next devlog (which hopefully won’t take a week this time).

Anyway, I also started working on the settings app (image two). The “update” buttons don’t do anything right now, but they will soon. Thank you for reading through this devlog and have a great day!!

Devlog 05

A pretty small devlog today. Just got the M+ button working with the currently open windows. The problem with the clipboard history is that I have to get website permission from the user to do that. I don’t really know how to do that, so I’ll work on that either later today or tomorrow.

Devlog 01

What is Glide?

Glide is a Mac note-taking/task planner app built for students. You take notes and create tasks by typing things like “9:00 [] Integral rules homework @daily.” The tasks are then parsed live into a clean, structured timeline. In the future, we want to make an iOS app, add sync, and more features that will help students. Also, I’m making this app with @aarnav_sharma and @harieshkarth.

Why Glide?

Every other note-taking app that we’ve tried is either overwhelming or missing features students (like us) would want. Glide is our attempt to fix that.

What I did in these 90 minutes

Now that you guys have some content on the app. So far, I’ve made a basic window so that I can on the line parsing stuff. The images attached show you what the line parsing (as of right now) is doing.

Devlog 04 - Browse your FILES

Finished

I wrote instructions on how to use the operating system in the Welcome app. Also, as I said I will last time, I made an app. It’s called Root because “root directory” and the math term “root”. It’s not the best name ever, but it’s good enough. Speaking of names, for the calculator/search thingy, I picked the name Operator cause it controls a lot of the OS.

Next Up

Now, I’m going to ship this OS. Then, I’ll work on the M+ button (the clipboard manager and app switcher for the operating system), the math store idea where you can download apps for different math things, and a settings app for customization.

Devlog 03 - FINALLY the MATH

Finished

Last time, I said I was going to make more apps before I do the calculator. However, the calculator seemed way more fun than random math-related apps, so that’s exactly what I worked on. As you can see in the images, you can now do math in the calculator searchbar thingy (still need a name for it), and you can search for apps.

Next

This time, for real, I’m going to make more apps. I’m probably going to start with a file explorer that shows previous math calculations as files.
After I’m done making a couple of apps, I’ll work on the clipboard (the M+ button from my previous devlogs).
Once both of those are done, the OS should be ready to ship, and for my second ship of the OS, I want to make the math store and add customization.

Devlog 02 - All the windows you want

It’s been way too long since my previous devlog.

Finished

You can now create multiple windows of the same app (as you can see in the image) by clicking the × symbol at the top.

I created an “apps” folder in my project to store HTML files, and each file contains a single div that holds an entire app. This setup should simplify developing more apps in the future since all I have to do is create an html file in that folder. This new system of making apps meant that I had to change the loading app logic in script.js, but luckily, it wasn’t that different to the previous logic.

Selected windows now actually look different when compared to unselected windows. It took me a while to figure out how to do that CSS effect, so hopefully that was worth it.

Next

Now, I’m going to work on actually making good looking apps that have more than just text in them.

Then, I will on the calculator search menu that will eventually control the entire operating system. Still not completely sure how that’s going to work though.

Devlog 01

Finished

• A top bar (inspired by MacOS)
  • M+ will be the clipboard manager
• Four operations (+/-/x/÷) at the center of the top bar; these control the selected window
  • +: maximizes the window
  • -: hides the window
  • x: creates a new window for the selected app
  • ÷: quits the selected app
• Window manager logic that allows multiple windows of the same app (by duplication html and using IDs for each window)

Future Plans

• The main calculator menu (like a search bar, but a calculator and everything in the operating system will be controlled from here)
• A file explorer to look back at previous calculations (history files)
• A math store (app store) to install higher levels of math; I don’t know what the higher levels of math will be used for in the OS, but yeah

Note

divs have to be the best component in html

Devlog 05

Finished cleaning up the repo and wrote a temporary file explaining how to manually install the extension, then submitted it to Raycast for review.

Raycast’s review bot then caught a handful of bugs I hadn’t noticed. So, I fixed those bugs and pushed those changes. I also swapped the C++ documentation code out for code that safely parsing the data as plain JSON instead of using eval, so it only ever reads data and never executes anything. During that process, I also got a bunch of TypeScript errors due to not properly giving everything an object type.

The extension is now in Raycast’s review queue. Next up is just waiting on that, and addressing anything else reviewers flag. In the meanwhile, anyone that wants to try out the extension can manually install it using the Try it Out link.

Devlog 04

The Python documentation feature turned out to be very annoying. The search index url I am using to fetch the documentation was being way too inconsistent. Half the time, it gave the data and half the time, it gave back a Cloudflare auth page. So I decided to drop that feature entirely. Here is the search index url I was using in case anyone knows how to get past the auth page: https://robotpy.readthedocs.io/projects/robotpy/en/stable/searchindex.js. The screenshot shows what is supposed to fetched from this url.

I also built a feature to look up status indicator lights for various FRC hardware components, but realized there’s already a single webpage that has all of this information laid out well. So instead of rebuilding that information inside the extension, the feature now just opens that webpage directly.

Next up, I’m going to finish tidying up the repo, write a temporary instructions file explaining how to manually install the extension (since it isn’t live yet), and submit it to Raycast for review so it can be officially published.

Devlog 03

I improved how the extension fetches the Java documentation. Instead of fetching 600 something URLs (one for each class in the WPILib library), it now only fetches one search index URL.

I also got the C++ documentation lookup feature working. Unfortunately, the C++ documentation’s search data doesn’t include as much detail as the Java one. It doesn’t tell you what functions each class has, so the C++ results are a bit more bare-bones for now. You can see what it looks like in the attached screenshot.

I’m currently working on adding Python documentation support. It’s been a bit annoying since the search index URL for the Python docs sometimes is sending HTML instead of javascript. Once I get that fixed, I can finally get to the motor/sensor lookup feature.

Devlog 1 (8 hours left)

Game idea: a game where players draw wet ink paths to guide origami pieces from printers to demanding shredders before the shredders destroy the page. To succeed, players must manage traffic to prevent expanding ink lines from cutting the paper and direct origami pieces to break random ink cartridges for more ink resources.

This game is for a game jam that started Wednesday and is due at the end of the day. I only had time to work on it yesterday. Today, I have all of today, but we’ll see if I can finish in time.

So far, the player can draw ink (the blue line below) and printers (the white boxes) spawn in randomly every ten seconds.

Devlog 02

The extension can now fetch the Java WPILib (the library mainly used in FRC) documentation and display all the classes and methods in the library. Once you fetch the documentation (takes ~one minute), you only have to fetch it again when you want to update what you have cached.

Tomorrow’s plans are to show descriptions of classes, show descriptions of methods, and add either Python or C++ WPILib documentation.

Devlog 01

As of right now, the unit converter (the command in the video) is the only part of the extension that is completely done. Most of the unit converter was done last week. Today, I added the action menu so that you can copy the answer and quickly put it in the search bar.

In the future, I plan on adding a WPILib (the main library used for First Robotics Competition coding) documentation viewer, a motor/sensor status lookup, and a robot status monitor (that would be in the menu bar).

Posting this early the development in order to get some feedback.