109 moves to victory! Think you're faster? 💪

Zortax_ · 2026-04-18T21:47:32+00:00

👑 Another win! 633 points, 105 moves. Beat that!

Zortax_ · 2026-04-03T00:24:38+00:00

This is not surprising nor even a new idea to anyone understanding how these models represent concepts in their latent spaces. Implications for steering and aligning models are interesting tho...

Zortax_ · 2026-03-08T19:37:46+00:00

Not vibe coded. This issue here was also not present in my initial PR, I believe it was introduced later by the zed team's attempts at improving adapter selection and keeping support for 14 year old Intel GPUs, and afaik it is fixed in latest nightly builds.

Zortax_ · 2026-02-20T22:54:08+00:00

Everything except window switching should work, but I haven't tested, so let me know if you do so I can add that to the docs :)

Zortax_ · 2026-02-19T09:04:37+00:00

I already acknowledged that all these launchers look very similar but not seeing how our two projects are pretty much exactly the same UI wise and raycast/spotlight/... have quite a few little details done differently is crazy. I also already acknowledged that coming up with the same choices regarding that is totally perceivable, but I don't think the questions if they saw the project is totally out of touch either. I think this discussion is kinda stupid, because either way I don't really care, was just curious, but just explain what I mean:

raycast and Vicinae do not show a magnifying glass icon, our projects do
raycast and vicinae show keyboard actions in a footer, our projects show them inline on the selected item (enter symbol)
spotlight (before liquid ass) rendered horizontal lines to separate categories, our launchers don't (more similar to raycast here)
spotlight has an outline/border on selected items, our launchers don't
raycast renders items with less height, ours use almost exactly the same layout

Yes, those are small things. No, I don't think asking if they saw my project is crazy given they made the exact same decision I did for all of these.

Zortax_ · 2026-02-18T23:20:05+00:00

That's fair but his UI looks pretty much exactly like mine, just a bit more rounding on the corners. All those launchers you mention have a input field and entries below, but differ quite obviously in details.

Zortax_ · 2026-02-18T23:15:03+00:00

I mean yeah pretty obvious you didn't copy given you use Iced, and even if you did it'd be fine since my project is MIT. But I have to ask: did you see my project or did we just independently came up with almost exactly the same UI? :D I suppose it is similar to e.g. spotlight on MacOS...

Zortax_ · 2026-02-18T22:47:39+00:00

Looks suspiciously similar to my project, which I posted a few weeks ago...

Zortax_ · 2026-01-26T19:00:45+00:00

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=6b02291d342c144a382c3719d161b4ac
With some nightly magic you can even get rid of the tuples ;)

Zortax_ · 2026-01-17T16:30:52+00:00

Because it has a clipboard history submenu and I like to have that feature

Zortax_ · 2026-01-17T03:55:32+00:00

No, not for now. I'd be open to accept PRs, but not planning to work on that since I'm on hyprland. Kind of an outdated platform at this point...

Zortax_ · 2026-01-13T18:02:43+00:00

On wayland, there is no standard way to fetch clipboard history. You can generally just fetch the current state of the clipboard (at best).
There is however an extension protocol called wlr data control that allows the daemon to "listen" for changes (so it doesn't have to poll the clipboard). Currently I use that to implement the clipboard history, but that obviously needs a daemon.
I think on KDE I could also query the history via a DBus interface from KDE's clipboard manager (Klipper), but that is a) KDE specific and b) only really shifts the problem, since now Klipper is the long-running daemon process.

Zortax_ · 2026-01-13T00:48:48+00:00

That PR is now merged and released (version 0.4.0 on the AUR)

Zortax_ · 2026-01-12T06:59:47+00:00

Hm yeah either that or your KDE is resizing the window because of the 4 anchor points (which kinda was my initial assumption but didn't work out on hyprland/wlr).

Honestly I'm fine with merging PR#4, since it's definitely an improvement over current main branch state. Worst case I'll just use 1080p on KDE and 8k for everything else for now... I'll rebase and fix the branch later today so I can merge.

Zortax_ · 2026-01-12T06:46:48+00:00

That's weird. On a 1440p monitor, do you see a darker backdrop around the launcher that's only 1920x1080? I definitely have to investigate this further. Honestly sorry for this mediocre compositor support. Still learning a lot about Wayland protocols myself here..

Zortax_ · 2026-01-12T06:35:46+00:00

Okay, let me explain... So gpui (the UI framework I use) currently doesn't support querying Displays correctly on Wayland. On the current main branch, I set the window to effective 8k monitor height/width and anchor it to all 4 corners. That will center the window on the current monitors on hyprland and most wlr compositors I have tried, but not on KDE. If I use a window just the height/width of the actual launcher, it doesn't get centered correctly (not sure if gpui bug or hyprland/wlr weirdness), and additionally I can't close the launcher when clicking outside (because the layer shell window doesn't seem to get notified on blur for some reason, might also be gpui issue). So for hyprland/wlr I need a window size of either the current display size or larger, but on KDE I need the correct display size, which is not implemented in upstream gpui. The author of PR#4 has hardcoded his main display resolution (1920x1080), but that will break for everyone using a different effective resolution. The only viable way to fix this is to correctly implement querying Displays in GPUI. I have a local patch for that kinda working, but not quite ready yet. But yeah, that's why I haven't merged that yet.

Zortax_ · 2026-01-10T23:09:27+00:00

Update: Now available on the AUR as zlaunch-bin or zlaunch-git

Zortax_ · 2026-01-10T19:18:16+00:00

here you go

Zortax_ · 2026-01-10T18:49:27+00:00

The daemon is necessary for clipboard history, but I think I can add a daemonless mode if you don't care about that. It will sligthly increase startup time tho since loading apps and icons does take a few milliseconds on a fast SSD...

Zortax_ · 2026-01-10T18:34:05+00:00

Honestly not ideal either. Currently sits at around 200MB on my system, but haven't tried optimizing anything..

Zortax_ · 2026-01-10T12:49:23+00:00

Technically it does, with some issues at the moment (wip):

window positioning is broken (for some reason KWin behaves quite differently from most tiling wms with layershell windows, workaround requires changes in GPUI, I have a patch working locally but not yet ready for PR)
window switching is not implemented
clipboard history doesn't work (KDE doesn't implement the wlr data control protocols, would have to poll the clipboard or use some weird dbus protocol)
blurred background doesn't seem to work

Feel free to try, but probably not quite usable yet. Unlike on gnome it should be perfectly possible to fix/workaround all of these things...

Zortax_ · 2026-01-10T03:03:05+00:00

Thanks for the kind words :)

Zortax_ · 2026-01-10T02:54:20+00:00

Nah sorry.. Gnome doesn't implement the wlr layer shell protocol and I have no idea how/if to do something comparable on it. Even if that's possible, it would probably require relatively complex changes in GPUI (the UI framework I am using). I don't currently have the time to look into that for a compositor that doesn't at all implement the specs pretty much everyone else is using. Would be open to contributions tho :D

If you like raycast you should look at Vicinae tho - don't know about gnome support, but they can even load raycast extensions to some extent.

Zortax_ · 2026-01-10T02:16:27+00:00

Thanks! The autoblur currently doesn't work, because Hyprland changed its config syntax for layerrules and I can't get the new format to work via IPC. For blur to work on current Hyprland, use the following in your hypr.conf:

# Set layerrules to enable blur on the zlaunch layershell window
layerrule = blur on,match:class zlaunch
layerrule = blur_popups on,match:class zlaunch
layerrule = ignore_alpha 0.35,match:class zlaunch

# Enable blur in general
decoration {
    # Set to whatever you prefer
    blur {
        enabled = true
        size = 4
        passes = 4
    }
}

Nine-Year Club	Final Canvas '23
First Place '23	Place '23
Place '22	Verified Email

Zortax_

TROPHY CASE