we now cache the last 32 images, fetching from the backend when required and updating the cache. made the image re-rendering issue instantly better.
attached is the demo video i forgot to upload in the second to last devlog showing images in action.
images are a difficult thing to handle, especially when dealing with the system clipboard. i’ve made Squirrel as performant as i could to the best of my abilities, which is to say, it’s not the best. it isn’t as rich as i would like it to be, so i might return to this feature to improve it in the future.
one restriction i’ve put on images to control some of the chaos is limiting the size to 5 megabytes, meaning any image above 5 megs isn’t registered. i could push that to 10, which is still practically instant. but Squirrel is intended to be a quick clipboard, and not dropbox. so this is my cheaty little escape. maybe i’ll relax the limit in the future if 5mb is really restrictive.
i’ll probably bump the minor version and ship (i wouldn’t dare a v1.0 currently). i’d say pinning and image support is enough to warrant a second ship.
beyond that though, stands file(s) support, so a lot of decision making on how i want it to work to have a good balance of performance and usefulness.
a bit of a lengthy devlog this one, and i appreciate if you read all that. but i wanted to clear up some things for myself and just have a frame of reference where Squirrel stands right now after returning from a development break.
yay, yippee even.
i need to implement a frontend cache to store the last X entries’ contents, particularly for images. the way it works right now, every time the images are re-rendered (due to being filtered by search, for example), content is fetched from the backend. this ofcourse, is less than ideal. but shouldnt be a lot of trouble to fix.
some performance enhancements with images. made the clipboard image data fetching happen in Tauri’s dedicated thread pool, effectively parallelizing the operation. this made image copying a lot faster. image support should be merged into master soon enough.
we now have lazy loading for images. image data isn’t loaded until it is scrolled into view. makes startup quick.
enabled Dependabot updates and optimized the lint workflows for PRs. previously, all of the project was lint+checked on PR when changing anything. now it only checks the part that’s changed (i.e. frontend or backend)
we finally have some form of working image support in Squirrel. This required even more sweeping refactoring changes to the codebase, which was a bit painful and im sure the new code isn’t the best quality either and will bite me later, but we’ll deal with it when we deal with it.
getting images is a bit slow however, as right now we’re storing the image as base64 encoded PNGs.
i plan to use the SQLite blob type to just store the raw bytes and pass that back and forth to improve the performance a bit (maybe some sort of caching as well?). there are also other areas where that are to be improved but i wanted to get a somewhat working prototype as fast as i can.
i’ve been distracted by some life stuff, making me neglect my projects a bit. i also got distracted by the ESP32, fun little device. that is where the 9 days went. but, expect me to work semi-regularly again. thanks for reading.
(apologies for the uneventful devlog attachment, i have nothing interesting to show except just code)
to make it a bit more manageable when adding image support, a bunch of refactoring and reorganizing has been done in the backend.
like i’ve previously mentioned, the codebase leaned too hard into only supporting text events. this fixes that.
today’s changes also make the internal communication a bit more efficient. there are a couple more places where performance can be improved. and we will need every bit of performance we can get when dealing with image data.
(shoutout @Hridya for stardance utils, just discovered this)
currently writing the Release workflow for Squirrel. i have to figure out how to upload the artifacts to a github release with proper versioning and all that. the strategy is to run the workflow whenever something is pushed to the release branch.
that is all for today.
bumped the minor version. Squirrel is officially v0.2.0, yippi.
plus, updated the README, adding more explanation about the Wayland issue. also showcased the pin feature. i’ll try to whip up a release workflow to add to my CI tomorrow.
I’m debating whether i should ship v0.2.0. the only major change from 0.1.0 is the addition of pinning. i might wait until i have image support and ship later, or i might change my mind, im unsure.
moved the global launch hotkey logic from the frontend to the backend. it didn’t behave well in certain situations, failing to activate and bringing up the Squirrel window.
we’re experimenting with images. the current functionality is very much caveman and needs a lot of attention to make it actually usable. i’ve decided to stick with clipboard_rs for now, we’ll see how that pans out.
so i just found out that Tauri’s global shortcut plugin does not yet support Wayland, which is sad to discover this deep into development. but, there is an active PR addressing this issue, which is nice. what this means for Squirrel is that proper Wayland support will unfortunately have to wait until this is merged.
the joys of using a not-yet-completely-matured framework i suppose. though it does make me feel a bit guilty for calling Squirrel “cross-platform”.
--silent launch flag that makes it start with the window hidden. useful when the app is set to launch on system startup.Ctrl+Shift+Del will clear history permanently. (i forgot about clear history functionality in the first ship even though the code for it existed, there just wasnt a button in the frontend to call it)dipped my toes into github workflows, messed around, an got check&lint workflows working on pull requests. will make a release workflow some time later. this change however, was only a part of this devlog’s time.
turns out, using clipboard_rs might’ve been the subpar choice for interfacing with the system clipboard. while clipboard_rs provides a easy way to listen to clipboard changes and get text from it, fetching raw clipboard data is buggy and inconvenient. when i sat down to work on image support, i was immediately brick-walled by how messy it is to just get raw data first. it would’ve been simple if i was building for just one target os but considering both windows and linux, it’s less than ideal. on top of this, the documentation for the crate is very lackluster.
all this to say, i am very much debating migrating my clipboard stuff to using arboard. arboard doesnt provide direct functionality to listen to clipboard changes so i will have to implement that myself. but, it does have first class support for wayland. a very enticing choice, but we will see.
I’ve improved the IK through changes to: billateral limb distance (so
far there was nothing in between for example 2 legs), timing
adjustments, joint rotating planes, computed target body height and body
center of mass, … Next up is animating limbs that aren’t legs! any
feedback?put it in the comments (pretty please)
I have locked in my capacitor, toroid, and have changed electrode selection
2, Inductor choke:
From:
KS130060A: Bulky, weird, overpowered, takes too much space
power smd inductors: unavailable, weak
To Now:
4x T90-26 toroid core, stacked, and hand-winded, handles current adequately, slim (fits into the wand shape)
I initially wanted to use acorn nuts with machine screws, and lug terminals, but I figured out they were too bulky for this project
I remember something:
solid copper cables, especially pvc insulated are available everywhere, has high thermal mass (for 2.5mm cross sectional area variant), and it makes for a great electrode, how? by stripping the insulations off of 8/10 of the length, and then wrap copper coils of off other stripped copper wires so it acts as a heatsink and provides better thermal mass and it adds to the aesthetic
and so I picked 2.5mm NYA Solid Copper wire as the electrodes, I hope I can glue it well…
also previously I had recorded 3 hours of work in lookout but it didn’t registered to stardance…
In that 3 hours I searched for the mosfet, diodes, capacitor, and the power supply, aswell as searching for the best way to pot a high voltage transformer, I ended up with a BOM like this
it’s an updated one, in the next session I’m planning to uhh design the CAD for the ZVS HV Wand, and I would try to finish it in 2 hours, it should be easy to print, minimal support, easy to grip, and would not cost more than 3$ or about 50.000 IDR, because I use an external 3D printing service, I need to make it as light as possible while maintaining strength and comfort, don’t worry about the prices and quality though, I have used this service, it gave insanely cheap price, and the build quality is surprisingly well for a cheap 3D printing service (PETG).
slight refactoring and bugfixes for frontend navigation. the navigation was kinda wonky before this and sometimes wouldn’t highlight the entry that was actually selected in the background. most of this devlog’s work was to make it so that what you see is what you get.
also, a touch of color has been added to pinned entries (tentative).
we now have basic entry pinning support. this was a bit less difficult than i thought it was going to be. but now you can pin an item and it always stays at the top of the list (unless you’re searching). anyways, that is one item ticked off the todo list.
apart from that, i had to do some minor backend refactoring and reorganizing so that it is easier to build more upon.
image and/or file copy support. this is one monumental task. i think the way we’ll approach this is by storing the entire file if it’s smaller than, say 5mb, and if it is larger, we just store the path to the file. we dont want to store the user’s 5gb video file they just copied.
for images, i think the play is to generate a low quality thumbnail of the image to display in the app. for files, if it is a text file, we can show just the first 5 or so lines with a link to the file, other wise we’ll just give a link.
until now, the code i’ve written sadly relies too much on the fact that every event is a text copy as we ignore everything else. it’s going to be a rather painstaking experience refactoring the codebase.
the challenge is going to be keeping Squirrel quick and responsive while supporting all of this additional functionality.
ofcourse critical bugs pop up when im trying to release.
the system tray icon wouldnt show up when running the single-file executable on any platform. that is now fixed.
plus a couple more things have been done to make Squirrel behave like a good cross platform app, like storing the data in the OS’s appdata directory.
there are some more things i would like to do but i think the app is in a releasable state and i’ve wanted to ship it for a while. I’ve set up the GitHub release and all the relevant instructions in the README. might be last devlog before ship #1.
more readme refining, linux support clarity, and installation instructions.
also, i completely forgot about the tray icon actually needing an image icon, so until now it was just blank. anyways, we now have an icon.
next, we put out releases on github and ship, hopefully. unfortunately we have to wait until tomorrow for linux builds.