1.09

We are getting so close to the first demo launch!
Pushed by my Git fascination I managed to integrate another two important things into the repo: CodeQL and automatic code review by CodeRabbit. However I realised I’ve been doing much more things at the repo itself and I keep forgeting I am trying to code something. So - 4 new features (and first really developer-focused) and incoming REAL readme (because the current one is really crappy).
I just started my last high school year so I’ll be a little more busy but my targets still remain the same: at least 80h on stardance and first beta release until 30th September.

What I’ve made

• Git integration with status bar, staging, discarding for directories with repos present
• improved navigation with folder history (go back, go forward like every normal file manager)
• sidebar tree view instead of Finder-like fixed bookmarks (like Windows Explorer, kinda buggy for now but actively working on it!)
• file collision handling with choice dialog window

What I’ve learned

• a bit of project management (kanban, agile etc.)
• Git API usage in Swift
• handling and applying code review reports
• CodeQL reports analysis

Difficulties

I must admit that I did not write unit tests for Git integration because I kinda don’t know how to approach it. Maybe the next few days in school with my teacher will help me going through it.
Apart from that I struggled with applying some responsiveness to resizable elements (such as InteractivePathView) and eventually failed and will return to this later.

---

I promised myself that I won’t go beyond those 10h of no devlog but I failed again. My own devlog template is incoming so I will be more eager to make them more frequent.
Apart from that - I am planning demo launch around 14th September so I can gather feedback before beta release around 30th September. Thank you all in advance for reading this and till next time!

19.08

I’ve made myself a little break, I admit. It was a good time, I came back stronger and more motivated.

I’ve noticed that the project is terribly documented and tested, files orgranization was also looking bad. I decided to correct those affairs to make the further development more… amicable.

There was also some time for new feature: searching. Maybe not the best but it is already better than Finder’s (modest as always, I know) because it has revelance tier sorting. Of course it is not the final version but for now It’ll work.

What I’ve made

• extended unit tests to have code coverage level at 68%
• experimented with DocC documentation and found it quite usable so I’ve made documentation for plenty of structs and methods
• organized files into a new structure (MVVM model)
• tried to reduce or just identify technical debt inside the project

Sounds easy right? Swift Testing framework is easy but it took me some time to learn good practics (and I’m still learning).

What I’ve learned

• reading Develop in Swift Fundamentals, covered a lot of holes in my knowledge
• code review by my friend, almost 2 hours of discussion and disappointment

Also I have plenty of reflections about the technical debt meant earlier. I realized that if I want to efficiently go further with the project I have to think more carefully about planning and organizing the development process. Hopefully the next school year will teach me how real programmers do the thing.

---

That’s all in today’s Not-So-Daily. I know I say that again but maybe it’s time to try doing devlogs more frequent than 10h of work. I didn’t even realize it went that fast. Till next time!

02.08

I tried to write a devlog several days ago but excessive heat beat me up.
To be honest last week was the hardest during the whole project. The amount of documentation and videos I’ve read and watched was enormous. My head is overload and I may be considering a little break. But let’s get to the stuff what was made. As usual the full devlog will be posted on toriyukari.neocities.org website.

What I’ve made

Last Stardance devlog was 21 days ago so it was basically the very beginning of the project, so I’ll just write things that are already present:

• fast directory loading with grid view (better functionality) and list view
• sidebar like that in finder (not fully functional as the finder one)
• toolbar with “go up” “refresh” “showhiddenfiles” “sort by” and interactive path view
• multi-selecting files with shift (range), drag (area) and command (specific)
• drag and drop files (single for now) to other apps as well as between directories inside the app
• right click menus on empty space and elements with the following options:
  • open with app
  • reveal in finder
  • file info (opening a dedicated element info window like this in finder)
  • copy, cut, paste elements
  • inline rename
  • compress to zip
  • trash
  • open directory in terminal/vscode
  • create folder/file
  • copy shell-formatted path

I am currently preparing the project to move into Test Driven Development, I am trying to cover the whole existing source code with tests to go on with this coding practice.
Soon I’ll start learning about UI testing in Swift Testing framework.

What I’ve learned

I can’t even think about how many things I’ve read about during the last 3 weeks. Maybe if I would be doing this list regularly… that is actually a good idea.

But most important thing that caused me to almost destroy my repo was: DO NOT LET GITHUB COPILOT CREATE COMMITS FOR YOU. They didn’t improve anything and now I have a freaking Copilot as a contributor in the repo. Worst mistake of my life.

Difficulties

EVERYTHING!

But seriously since I use as little AI as I can I am going through hard time during almost everything. Sometimes it drives me crazy.

The biggest difficulties were:

• removing the freaking slopilot from contributors (failed)
• running my mind at full throttle to understand the crazy UI code splitting (the compiler can’t parse large elements without splitting it into separate elements)
• running both “drag and drop” and “drag selection” at the same time without generating errors no one have seen before
• setting up codecov for swift in a new way because apparently no one has thought about any different way than travis for the last 7 years
• writing custom EULA and source code license (it will be used for all my future project so it was worth to invest some time and money into it)

And that’s all worth to mention.

Storytime

HEAT WAVE HEAT WAVE HEAT WAVE HEAT WAVE

WHY IN POLAND IT HAS TO BE -15C OR +40C WHY IT CAN’T BE FREAKING NORMAL 20C

HEEEEELP I CAN’T WORK NORMALLY!!!

…

i’m fine

---

I’ll try to make devlogs more frequently but I don’t think I like doing so. I’ll have to think about some formula, maybe a simpler approach, more reusable scheme or something like that. Until that going off the air for a moment to rest. See ya!

Announcement

Hi everyone! Little update here: I will be posting full sized devlogs
for RiverFlow and any other project on my website available at this
address: https://toriyukari.neocities.org/

I am an enthusiast of big, bulky devlogs where I do not only write rough
code facts but I’m also sharing a whole development story and 4000
chars is not enough for me.

From now on I will be making a Stardance devlog version and full devlog
version. I will be attaching a link for everyone who are curious about
the whole process. I hope you all understand this.

Also there is a first instance of brand new idea of mine available on the website: daily where I share the status and changes of the development every day. You should check it out cause they won’t show up here.

Anyways, have a great day just how I’ve had! See ya!

Devlog #1

Until now the project was simply a prototype to test the idea but I kind of lost track of the time and made way too much before first devlog.
So here it comes: RiverFlow, native file manager alternative for MacOS, part of The Shrimple Project.

Fast as river, no one can stop the flow. It uses all the best stuff Swift language has to make it more resource-efficient than Finder (at least that’s the target) and it’s currently my biggest project.

It is ultimately intended to be developer-friendly and will have a lot of built-in tweaks we as programmers needed a plugin for. I also wanted it to have some Linux-feel and make it customizable in every possible way: from colors and icon sizes to custom windows and built-in plugin maker.

How it actually works

(I had to cut this cause of 4000 chars limit, I will post full devlogs somewhere else)

How it ACTUALLY works

Alright, I’ve been talking about something entirely different. So here is the flow:

1. You run the app. First you see all the windows attacking you, begging for permissions but it’s irrevelant. The run calls loadCurrentDirectory method from FolderViewModel class. It is the heart of the app, lCD method (as I call it) is being called every time something happens (well not really automatically but I’ll get to it later).
2. lCD creates multiple FileItem class instances. That’s your folders and files as raw data! It also sorts them by your selected method (name / size / modification date) on place.
3. In ContentView depending on which viewType has been selected (list or grid) list/gridView is being rendered. For each FileItem it creates FileList/GridItemView, that’s a view for a single file/folder.

And that’s it! If I would want to I can fit all of this in 50-100 lines of code. The real fun starts in coding user interactions with all those objects. I must admit it wasn’t the easiest challenge.

The difficulties

The list is long. I’ve encountered several walls on my way, some cleared up by different websites, for some I had to use AI tho.

The “minor difficulties”: I’ll spare you this rant

The “major difficulties”:

• caching thumbnails for images (and even just making them display and not eating 300 MB of RAM instantly when generating)
• making the full path in toolbar (the animations and proper detection)
• efficiently calculating folder size in Info window
• implementing shift and drag select (took me freaking two days to figure it out)
• making the SwiftUI cooperate with me and not destroy my entire GridView when adding print somewhere

Features list

• main window listing files and folders in two views: list and grid
• toolbar featuring full path copying, sorting, view and hidden files options
• sidebar featuring most used folders resembling the one from Finder (not customizable yet)
• files and directories operations:
  • copying, cutting, pasting, deleting multiple files
  • selecting items with shift (range), command (specific), drag (area)
  • creating empty folder and file from context menu
• item info window showing full path, name, icon, size, modification date

There isn’t much features yet but taking into account that I am using Swift for real for the first time I am proud of myself.

---

I hope you all will like this project and find it useful in your every day productivity when it’ll be a finished product. Until next time! I will go make myself a real dinner for the first time since two weeks.

For the last 30 minutes I’ve been preparing the app’s GitHub repo for shipping process along with small changes:

• defining the text size limit (20000 chars)
• fixing shortcut malfunctioning

I got tired of MacOS not having any core implementation of clipboard with history and all the paid apps that implement this so I’ve made my own. Introducing to you the prototype of JarvisClipThat being part of The Shrimple Project - my solo initiative to develop several minimalist MacOS apps filling the gaps in productivity many users have encountered.
This is the first app of this project and so far it implements:

• working clipboard history - you can take any item from it to your current clipboard including multimedia like images
• burner mode - letting you temporarily copy items in an old way (new CMD+C removes the previously copied item)
• autostart

The app uses minimal amounts of device resources and stores the clipboard history in RAM when still not taking much space in it.

Current goals:

• improving privacy and security of the whole process
• some kind of optional synchronization with iCloud?

Devlog #4
What I’ve been working on since the last devlog is:

• adjusting the page design to be more user-friendly and eye-catching
• adding live stop timetable
• working on android version of the app using Capacitor
• improving overall documentation (including better business-like readme)
• deploying the app on a VPS to finally show it fully to other people

I still want to add another subpage for tracking a specific bus trip, better graphics for ongoing trip visualization, improving data displaying in stop timetable and add more variables to the estimation algorithm. I think about linking current and past weather and finding some cheap API to track ongoing traffic jams.

I’ve been on 3-days hold since I had to do CPR to my HDD but now everything is fine and I fully got back to the project.

Devlog #3
It was a milestone for my project, I redesigned all components interfaces + my friend helped me design the home page with css animations to look modern and professional. Also new functionality of authentication and users system who can now save their important trips.

For now the page is only in polish (this is target language) but I am working on english support again.

Devlog #2
For the last few hours I’ve been working on a dynamic feature to allow the user to finally select a bus stop not coordinates. Used node caching to do so. I am slowly moving into multiple website languages and color modes and setting up a public demo (tho I have to persuade my PC to run JVM on 90% of its RAM).

Current state of displaying trip plan. Uses OTP running on homemade server and database of deviations built over the last week