A repository row that can be a whole folder of them, and a paste that arrives once.
What changed
A row can be the folder your projects live in
Projects do not always sit one to a folder. Point DevLobby at the directory
they live in, turn on Repositories inside, and that one row watches every
work tree under it and publishes their sum — ahead, behind, staged, dirty,
untracked, conflicted, all of it added up. Dropping such a folder on the window
does the same thing without being asked, because a directory that is not a
repository but has repositories in it can only have meant that.
The sum is an ordinary repository state under the folder's own path, which is
the whole trick: the header's chips, the spine colour and the row itself go on
reading one flat state and need no idea any of this happened. Only the branch
slot differs — a folder has a count to put there rather than a name, unless
every repository in it really is on the same branch, which is worth saying when
it happens. Rest the pointer on the chips and a card lists what it was summed
from, worst first: anything unreadable or half-merged at the top, then whatever
owes the most, and the clean ones settled alphabetically behind a count. A
repository that could not be read is named there but left out of the totals,
because adding its zeroes would report a folder as clean on the strength of the
half of it nobody could see.
Thirty repositories in a folder is thirty git status calls and thirty watch
handles, so the cost is held down three ways: the membership is capped, members
poll on a floor of their own rather than the window's interval — their .git
watches keep them responsive without it — and that floor is jittered per path
so they do not all come due on the same tick for the rest of the session.
Folders are walked again on a slow backstop; Refresh is what you press when you
have just cloned one.
Separately, the browser skill now installs into every Claude profile on the
machine rather than into ~/.claude alone. Two accounts side by side is two
configuration directories, and a skill written into one is invisible from the
other — which failed in the worst available way, because the first profile
answered for the machine, the bar found nothing left to do and took its own
install button off the screen, so the session that could not find
/devlobby-browser had no way to ask for it.
Ctrl+Shift+V no longer pastes the clipboard twice
Paste into a CLI running in a pane and the clipboard arrived twice, bracketed
once and then again, so the prompt read every line of it doubled.
xterm has no paste binding of its own. It sends ^V for Ctrl+V and leaves the
chords people actually paste with to the browser, picking the paste event back
up through a listener on its own textarea. Chromium's default for Ctrl+Shift+V
is a paste, so that path was already complete before DevLobby did anything —
and DevLobby's own handler, which reads the clipboard through the main process
rather than letting the page near it, was a second one on top of it.
The two only coexisted because of how app chords are kept alive. A terminal's
custom key handler returns false for a chord DevLobby owns so the event can
still reach the window, and returning false makes xterm bail out before its
own cancel() — no cancel is no preventDefault, so the browser went on to
run its default over the paste that had just happened. A chord we take now
cancels its own default.
Download
devlobby-1.2.0-setup.exe |
installs to your own user folder, so it never asks for admin, and adds Start Menu and desktop shortcuts |
devlobby-1.2.0-portable.exe |
one file, no install, no shortcuts |
Windows x64. Your repositories, notes and layout live in %APPDATA%\DevLobby,
and upgrading over 1.1.1 leaves them alone.
If Windows blocks it
These builds are unsigned, so SmartScreen warns on first run — More info,
then Run anyway. Smart App Control, where it is enforced, judges each binary
by its hash and can refuse outright with "An Application Control policy has
blocked this file". Building from source and launching through devlobby.cmd
runs the same app through Electron's own signed binary, which that policy does
not object to:
npm install
npm run build
devlobby.cmd
The README has the screenshots
and the full tour.