LinuxDoors AppImage Store
One file. Download and run.
Each of these is a single self-contained executable — the whole application plus the runtime it needs — that you download, mark executable, and run. Nothing to install, nothing left behind, and it runs the same on Debian, Ubuntu and other Linux distributions that can launch an AppImage.
Some are LinuxDoors' own work. Others are trusted upstream builds — we mirror them here unmodified, so you can get them from the same place as the rest of the system, each with a SHA-256 you can check against the project's own. Every app shows who made it and where it really comes from.
A recommended way imho to keep AppImages
This is Stan Switaj’s recommendation for how per-user AppImages should be stored — a tidy layout for the ones you download from the Store, with a real Desktop launcher for each.
One folder per user. Every AppImage a user keeps
lives in ~/AppImages/ — for the default account,
/home/linuxdoors/AppImages/. The AppImage files sit
directly in that folder:
/home/linuxdoors/AppImages/FlashScp.AppImage, and so on
for every other one.
One subfolder, for icons only. That folder holds
exactly one subfolder, images/, and nothing else. Each
AppImage’s icon goes there as a PNG:
/home/linuxdoors/AppImages/images/FlashScp.png.
A Desktop launcher per AppImage. For each one, a
launcher is placed on the Desktop. Its Exec= line calls
LinuxDoors’ own AppImage runner —
Exec=linuxdoors-run-appimage /home/linuxdoors/AppImages/FlashScp.AppImage
— and its icon comes from the matching PNG
(Icon=/home/linuxdoors/AppImages/images/FlashScp.png), so
the Desktop shows a real, recognizable icon for launching the program
instead of a generic one.
Why the runner. LinuxDoors has no FUSE, so an
AppImage unpacks itself before it starts; and /tmp is
cleared on every reboot, so a bare Exec= path re-unpacks
the whole app on the first launch after each boot — several
seconds with nothing on screen, which reads as “I clicked the
icon and nothing happened.” linuxdoors-run-appimage
(in /usr/bin, on every LinuxDoors install) unpacks into a
persistent ~/.cache/appimage-run/ instead — so each
AppImage unpacks once, ever, every later launch is instant,
and that one first run shows a “Starting… unpacking”
notification. You can still run any AppImage directly; the runner is
just the friendlier path for a Desktop shortcut.
In short:
~/AppImages/<Name>.AppImage for the program,
~/AppImages/images/<Name>.png for its icon, and a
Desktop launcher (Exec=linuxdoors-run-appimage …)
wiring the two together.
Showing all 10 AppImages.
FlashScp$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
Copy files and folders between computers, over SSH using scp.
by Stan Switaj · created August 30, 2026
A LinuxDoors AppImage Software Product
icon (.png)
scp, over SSH
SSH is the connection: it authenticates you to the far machine and encrypts everything that travels. scp is the copying: it moves the bytes, running over the SSH link that SSH established. FlashScp does not invent its own protocol and does not carry its own SSH library — it drives the real ssh and scp programs already on your system, the same ones you would type in a terminal. So your private keys, ~/.ssh/config, your ssh agent, known_hosts, ProxyJump through a bastion, and machines that demand a key AND a password all keep working exactly as they do in a shell. Nothing here re-implements authentication, so nothing here can get it subtly wrong.
Why scp over SSH is the right way
Everything is encrypted — your password, the file names, and the file contents. One port, already open: SSH is a single connection on 22, with no second data channel to fight NAT and firewalls over. Nothing to install on the far end — if you can ssh in, you can copy in. Keys instead of passwords, or a key combined with a password where a machine demands both. You can tell you are talking to the right machine, because SSH remembers each host key and refuses a substituted server. Corruption in transit is detected, because SSH authenticates every packet. And files arrive with their modification time and mode intact.
What is in the program
A Manager of Computers — every machine with its host, port, user, key path, optional password, starting folder and a note, plus a Test button. One connection per machine — the first connect opens a shared channel and every listing, file and command travels down it, so a password-protected machine is asked once, not once per file. The Queue — a dragged folder is walked and queued a file at a time, giving a real progress figure, several files at once, resume of an interrupted folder copy, and an optional speed cap. Compare and Mirror — see what differs by size and time between two folders and send only that. A Terminal tab, full file management (new folder / rename / permissions / delete, with a delete that names exactly what and where), light/dark themes with every colour measured to WCAG contrast, and a keep-alive that notices a dead link in about a minute.
What scp costs, plainly
scp has no resume of its own and no delta transfer — it cannot send only the changed part of a large file the way rsync can. FlashScp works around the first by walking the folder itself and skipping any file already complete at the far end; it cannot work around the second. scp also has more per-file overhead than FTP, so thousands of tiny files are slower — FlashScp answers that by holding one connection open and sending several files at once. And since SSH has no directory-listing protocol, FlashScp reads folders by running find on the far machine, falling back to ls.
Running it — nothing to install
Download the AppImage, make it executable, run it. It carries its own Python and interface libraries, plus sshpass for machines that want a password. It deliberately does NOT carry its own ssh or scp — those must be the ones on your machine, because they are what read your keys, ~/.ssh/config and known_hosts. Every Linux system already has them. Your saved machines live in ~/.config/FlashScp/FlashScp.save, created readable only by you; a password is written there only if you tick “Save the password”, scrambled (obfuscation, not encryption — the program says so). Otherwise it is asked once and kept in memory only, and handed to ssh through the environment, never on a command line.
Written for LinuxDoors, but nothing in it is LinuxDoors-specific — it should run on Debian- and Ubuntu-type systems, and on any other Linux distribution that can run an AppImage.
FlashPhoto$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
View, crop and adjust photographs — and crop a JPEG without re-encoding it.
by LinuxDoors · created September 7, 2026
A LinuxDoors AppImage Software Product
icon (.png)
Build 2 — the folder strip is off until you ask for it
Opening one photograph should not send the program off to read every other photograph in the folder first. In build 2 the folder thumbnail strip starts hidden and reads nothing off the disk while it is hidden -- it just holds the list of what is there. Press F3 and it walks the folder and decodes the thumbnails then, and only then; press F3 again and it stops, rather than leaving the reading going on out of sight. On a folder of large or raw-sized photographs that is the difference between a picture appearing at once and a wait while a hundred others are read. The state is remembered between runs, so if you keep the strip open it opens with it. Nothing else about the program changed: same viewer, same lossless JPEG cropping, same crop and adjust and resize and batch, same formats.
Lossless JPEG cropping
A JPEG is stored as compressed blocks, and the compression is lossy: some of the original detail went the moment the camera wrote the file. The trouble is what happens next. Open a JPEG in an ordinary editor, crop it, and save: the program decodes those blocks into pixels, discards the blocks, and compresses the result again from scratch. A little more detail goes each time -- soft edges, blotches around lettering, banding in a clear sky. That is generation loss, and none of it is recoverable. FlashPhoto does not work that way. For a crop or a rotation on a JPEG it hands the file to jpegtran, which copies the compressed blocks straight across without ever decoding them. The pixels that remain are bit for bit what they were, however many times it is done. It is a tested guarantee, not a claim: cropping a photograph this way and comparing against the same region of the original gives an identical set of bytes, and rotating four times by ninety degrees returns the file it started as, metadata intact. jpegtran travels inside the AppImage, so this works on a machine that has never installed it.
The one rule, and why the selection moves
Because it is the blocks that are copied, a lossless crop can only fall on a block boundary -- 8 or 16 pixels across depending on how the camera wrote the file. So while Lossless is ticked the selection snaps to that grid, and the grid size is read out of the file itself rather than assumed. Zoom past six times and the grid is drawn on the picture, so the snapping is something you can see rather than a rectangle that jumps for no reason. Snapping only ever grows the selection: a crop that quietly lost a strip you had included would be worse than one that keeps a few pixels you had not. Untick Lossless and any pixel is available, at the cost of a re-encode -- and the program says plainly which of the two you are getting.
What is in the program
The viewer: open a file or a whole folder, arrow keys to move; fit to window, actual size, or anywhere between with a fine-grained wheel zoom; drag to pan, double-click to switch fit/1:1, F11 fullscreen, drop a file to open. The wheel works either way round -- by default it zooms and Control moves through the folder; one setting swaps them. The next picture is already loaded: while one is on screen the program decodes the neighbours in the direction of travel, so moving to the next takes about three milliseconds instead of sixty on a twelve-megapixel photo -- and every held picture is re-checked against the file on disk, so an image edited elsewhere is never served stale. Crop tools: an eight-handle selection with a live readout of size, position and proportions -- double-click inside it to crop to it (or use the button), and Ctrl+Z puts it back either way; lockable to 1:1, 4:3, 3:2, 16:9 or 5:4; auto-crop finds the picture inside a plain border and offers the rectangle for approval. Adjustments: brightness, contrast, gamma, saturation and sharpening, previewed live, with transparency preserved. Resize by pixels or percentage with quick fits for a 1920 / 1280 / 800 long edge. A thumbnail strip of the whole folder, decoded at display size, off by default and toggled with F3 -- it reads nothing while it is closed, so opening a single picture never waits on the rest of the folder. A properties panel -- camera, lens, exposure, aperture, ISO, focal length, flash, date taken and GPS coordinates -- that docks left or right or floats, and follows you through the folder. Batch: the same change to many pictures at once (resize, convert, rotate, rename), every rename shown first, results written to a folder of their own, originals never touched. Light and dark themes, every colour pair measured to the WCAG contrast standard.
The formats it reads and writes
Reads: png jpg jpeg jfif webp bmp ico tif tiff gif ppm pgm pbm tga svg svgz xpm xbm icns cur wbmp j2k jp2, and PDF pages. Writes: png jpg jpeg webp bmp ico tif tiff ppm pgm pbm xpm xbm j2k jp2. Everything those need travels inside the AppImage, TIFF included -- nothing has to be installed on the machine for any of them.
Saving, and why it asks
Editing never overwrites the file that was opened unless you ask twice. Save As is the ordinary path and suggests a new name. Save on top of the original asks first, and says what it is about to do and where -- a program that can crop a photograph in one keystroke should not be able to destroy the only copy of it in the same one. A lossless crop or rotation always writes a new file on purpose: the operation reads the original and writes its replacement, and doing that in place would mean the one copy of the photograph is briefly the output of a program that might fail.
What it does not do, plainly
No camera raw -- CR2, NEF, ARW and the rest are not read; this is a program for photographs after they have been developed, not before. No layers, masks, curves or levels -- brightness, contrast, gamma, saturation and sharpening are the whole of the adjustment. An animated GIF shows its first frame; it is not a player. A lossless crop lands on the block grid by definition; cropping to an exact pixel means accepting a re-encode, which the program offers and labels rather than hiding. Metadata is read, not written -- carried across a lossless crop or rotation untouched, but the program does not edit tags.
Running it -- nothing to install
Download the AppImage, make it executable, run it -- optionally with a file or a folder to open (./FlashPhoto.AppImage ~/Pictures). On LinuxDoors, which has no FUSE, run it the way LinuxDoors runs any AppImage: ./FlashPhoto.AppImage --appimage-extract-and-run, or through linuxdoors-run-appimage, which does that for you and unpacks it once rather than on every launch. Settings live in ~/.config/FlashPhoto/FlashPhoto.save and are written when the program closes; deleting that file puts everything back as it started.
Written for LinuxDoors, though nothing in it is specific to LinuxDoors -- it runs on Debian- and Ubuntu-type systems, and on any other Linux distribution that can run an AppImage.
FlashZip$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
Open, extract and make archives — .7z, .zip, tarballs and more.
by LinuxDoors · created September 7, 2026
A LinuxDoors AppImage Software Product
icon (.png)
The formats it makes -- and the ones it only opens
Makes: .7z (the strongest of these, and the one to use for a backup), .zip (the one every computer on earth can already open), .tar.gz (the tarball everything on Linux understands), .tar.bz2, .tar.xz, .tar.zst (nearly as small as xz and far quicker -- a good default now), plain .tar for contents that are already compressed, and a single file compressed on its own as .gz / .bz2 / .xz / .zst. Compression runs from Store (packs without compressing at all) to Ultra, and an archive can be split into pieces of a chosen size -- 100 MB, a CD, a DVD -- for carrying somewhere that will not take one large file. Opens and unpacks, but does not create: .rar including the newer RAR5 form, .iso disc images, and .cab / .deb / .rpm packages. A .rar cannot be written here because the compression is proprietary and the only program that writes it belongs to the company that owns the format; opening and unpacking one is a different matter and works out of the box.
Passwords
AES-256, on .7z and .zip. The file names can be encrypted too, and that matters more than it sounds -- an encrypted archive whose file list is readable still tells anyone holding it that you keep tax_return_2026.pdf and a folder called divorce. Ticking “Hide the file names as well” puts the list inside the encryption, and the archive cannot be listed at all without the password. Nothing about a password is written down: it is held for as long as the archive is open and forgotten when it closes.
Being careful with your files
Three things it will not do, by design. It will not write outside the folder you chose: an archive can contain a member called ../../.ssh/authorized_keys, and both tar and zip will obey that unless somebody checks -- this checks, refuses such an archive with the offending name shown, and writes nothing at all. It will not replace something without asking: making an archive over one that already exists asks first, and extracting tells you where things are going before they go. And it will not leave half an archive behind: removing files from a compressed archive means rewriting it (no compressed format can cut a piece out of the middle), so that rewrite goes to a temporary file beside the original and is moved into place only when it has finished -- an interrupted delete cannot leave half an archive where a backup used to be.
What is in the program
The list: name, size, packed size, ratio, date and checksum for everything in the archive, sorted by any column, with folders that open like folders and a padlock on anything encrypted. Walking a large archive and taking one file out of it is the ordinary case, not a special one -- open the folders down to what you want, select it, press Extract, and only that file is written; one file out of a seventy-file archive takes about four milliseconds. In a solid archive the files are compressed as a single stream, so there is no packed size for one file in it; those rows say “solid” rather than pinning the whole block's size on whichever file carried the figure. Add and remove: put more files into an existing archive, or take files out, without rebuilding it by hand. Test: read every byte back out and confirm nothing is damaged, before finding out the hard way that the backup was no good. Information: what the archive is, how many files, how much it saved, whether it is encrypted. Long jobs run in the background with a progress bar and a Stop, so the window never freezes and stopping stops between files rather than part-way through writing one. Light and dark themes, every colour pair measured to the WCAG contrast standard.
On the command line
The same program, without a window, so it is as useful in a script as it is on a desktop -- the work is done by the same code the buttons use, including the refusal to write outside the chosen folder. FlashZip.AppImage -l backup.7z lists what is inside; -x backup.7z -o ~/restore extracts all of it; -x backup.7z docs/notes.txt -o ~/here pulls just that one file (or a folder name for just that folder); -t backup.7z checks it is not damaged; -a new.tar.xz docs/ notes.txt --level 9 makes one; -x secret.7z -p 'the password' for an encrypted archive; --formats reports what this machine can do. It reports properly: 0 when it worked, 1 when the archive was the problem, 2 when the command was, and 3 when a password is needed or wrong -- so a script can tell the difference without reading the text.
Running it -- nothing to install
Download the AppImage, make it executable, run it -- optionally with an archive to open (./FlashZip.AppImage backup.7z). On LinuxDoors, which has no FUSE, run it the way LinuxDoors runs any AppImage: ./FlashZip.AppImage --appimage-extract-and-run, or through linuxdoors-run-appimage, which does that for you and unpacks it once rather than on every launch. Settings live in ~/.config/FlashZip/FlashZip.save and are written when the program closes; deleting that file puts everything back as it started.
Written for LinuxDoors, though nothing in it is specific to LinuxDoors -- it runs on Debian- and Ubuntu-type systems, and on any other Linux distribution that can run an AppImage.
LinuxProPaintShop$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
Paint, retouch and edit pictures in layers, with unlimited undo.
by LinuxDoors · created September 7, 2026
A LinuxDoors AppImage Software Product
icon (.png)
The fourteen tools
Move (move the layer under the pointer), Rectangle select, Ellipse select, Freehand select, Magic wand (select everything of a similar colour), Brush (size, hardness, opacity), Eraser (rub out, back to transparent), Paint bucket (fill an area, with a tolerance you set), Gradient (drag one across -- linear, radial or angle), Colour picker (take a colour out of the picture), Clone stamp (set a source, then paint one part of a picture over another), Text (words on their own layer or the current one), Shapes (rectangle, ellipse or line, filled or outlined), and Crop (drag what to keep). Each has a single-key shortcut, and every selection tool feeds the rest of the program: paint, a filter or an adjustment applied while something is selected happens inside the selection and nowhere else.
Layers
As many as the picture needs -- add, copy, reorder, hide, rename, merge down, or flatten the lot. Each carries its own opacity and its own blend mode: Normal, Multiply, Screen, Overlay, Darken, Lighten, Colour dodge, Colour burn, Hard light, Soft light, Difference, Exclusion, Add. Transparency is real transparency -- the checkerboard under a layer is the absence of pixels, not a grey square painted on -- and every adjustment and every filter puts the transparency back exactly as it found it, the sort of thing that is invisible when it works and ruins an afternoon when it does not.
Fixing a photograph
Adjustments: Levels with the histogram drawn as you drag it; Curves on a real curve you place points on; Brightness and contrast; Hue, saturation and lightness; Greyscale; Invert; and Auto levels, which stretches each channel so the darkest pixel is black and the lightest white -- the first thing most photographs want. Filters: Blur, Sharpen, Unsharp mask, Emboss, Edge detect, Find edges, Soften, Gaussian blur, Noise. They are quick because of how they are built, not by being done at low quality: anything that can be a lookup table is one, run over the whole image buffer in a single call, so brightness, contrast, gamma, levels and curves land instantly on a picture of any size; anything that can be a composition is one, done in C; and what is left is genuine arithmetic across the colour channels, which is what the bundled numpy is for -- emboss on a 1600x1200 photograph takes about seven hundredths of a second.
The formats
Opens: png jpg jpeg jfif webp tif tiff bmp gif ico cur icns tga jp2 pbm pgm ppm xbm xpm wbmp svg svgz pdf. Writes: png jpg jpeg jfif webp tif tiff bmp ico cur icns pbm pgm ppm xbm xpm wbmp. TIFF is worth a note: most machines now carry a libtiff newer than the one Qt was built against, and on those Qt's TIFF support quietly is not there at all -- this build carries its own imaging library, so TIFF opens and writes here whatever the machine has on it. Its own file is .lpsp: the whole thing, layers and all, as a zip holding one PNG per layer and a small text file describing the stack -- nothing about it is secret or trapped, unzip one and the layers are ordinary PNGs, openable by anything.
Unlimited undo and redo
Everything that changes the picture can be taken back, meant literally: every brush stroke, fill and gradient, every filter and adjustment, the crop, the rotate, the flip, both resizes, and every layer operation down to its opacity, blend mode and whether it is showing. There is no ceiling on how far back it goes -- it starts at twenty-four steps, and when the picture reaches that it asks once whether to keep going or to stop at a number, and either answer can be changed later from Edit > Undo steps (lowering the number takes effect at once). It is affordable because of how a step is stored: a step holds the layers themselves rather than a description of what changed, so no operation has an undo that can be subtly wrong -- but a layer nothing has happened to shares its pixels with the live one, so most of a step costs nothing, and what has genuinely been painted over is squeezed down once the history grows past a quarter of a gigabyte, at about eight times smaller. Two hundred painted steps on a 1600x1200 photograph come to 255 MB rather than the 1.4 GB the same steps stored plainly would take, with every pixel back where it should be. Each step is named, dragging a slider is one step and not sixty, and closing a picture with unsaved changes asks first.
What else is in the program
The view behaves: zoom to fit, zoom to actual size, free zoom on the wheel in fine steps rather than doubling, and after a crop the result is centred rather than left hanging off a corner. The panels move: tools, layers and colours are dockable -- either side, stacked, or floated off as their own windows. It remembers: the theme, brush size / hardness / opacity, the tolerance, both colours, the JPEG quality, how many undo steps to keep, which panels are showing and the folder you were last in. Light and dark themes, switched with one key, every colour pair in both themes measured against the WCAG contrast standard -- the program will tell you so itself with --check-contrast.
On the command line
LinuxProPaintShop.AppImage picture.jpg opens that picture; --what-works reports what this machine can do; --check-contrast prints the contrast report; --version. --what-works is the honest one -- it says what is present on the machine and what each thing changes, rather than leaving you to find out by pressing a menu item that does nothing. In this build everything is present.
Running it -- nothing to install
Download the AppImage, make it executable, run it -- optionally with a picture to open (./LinuxProPaintShop.AppImage holiday.jpg). On LinuxDoors, which has no FUSE, run it the way LinuxDoors runs any AppImage: ./LinuxProPaintShop.AppImage --appimage-extract-and-run, or through linuxdoors-run-appimage, which does that for you and unpacks it once rather than on every launch. Settings live in ~/.config/LinuxProPaintShop/LinuxProPaintShop.save and are written when the program closes; deleting that file puts everything back as it started.
Written for LinuxDoors, though nothing in it is specific to LinuxDoors -- it runs on Debian- and Ubuntu-type systems, and on any other Linux distribution that can run an AppImage.
Kate$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
KDE's advanced text editor -- multi-document, project-aware, with an LSP client and a built-in terminal.
by KDE Community · mirrored August 30, 2026
icon (.png)
Upstream download: https://cdn.kde.org/ci-builds/utilities/kate/master/linux/
Editing, in depth
Open as many documents as you like, arranged in horizontal or vertical splits, and keep whole working sets as named sessions you can reopen later. Syntax highlighting covers 300-plus languages and formats; code folding, auto-indent, bracket matching and word completion come with it. Select in columns, place several cursors at once, and use a search-and-replace that speaks regular expressions and can run over every file under a directory in one pass. Prefer modal editing? Turn on the vi input mode.
Close to an IDE, when you want it
The bundled plugins do the IDE-shaped work without the weight. The project plugin notices a git, svn or mercurial checkout and gives you a file tree and a fast cross-file search scoped to it. The LSP client connects to language servers for completion, diagnostics, go-to-definition and symbol search in C/C++, Python, Rust, Go and many more. There is a terminal panel docked in the window, a build panel that parses compiler output into clickable errors, and Git integration for stage/commit/blame.
Mirrored, not repackaged
LinuxDoors did not build this and does not modify it. It is pulled straight from KDE's continuous-integration build server (cdn.kde.org) and served here unchanged, with its SHA-256 published so you can check it matches KDE's. The authoritative home for Kate, its source, its handbook and its issue tracker is kate-editor.org. If you would rather get it from KDE directly, that link is on the card.
Running it -- nothing to install
Download the AppImage, mark it executable, run it. Everything it needs -- Qt, the KDE Frameworks, the highlighting definitions -- travels inside the single file. Your settings live under ~/.config and ~/.local/share like any other Kate. To pin it to your panel or menu, most desktops let you right-click the running window, or you can use a tool like AppImageLauncher; LinuxDoors' own menu integration is on the roadmap for the Store.
KDE's AppImage carries Qt and the KDE Frameworks inside it, so it runs on most current Linux distributions that have FUSE (or with ./Kate.AppImage --appimage-extract). Built for x86-64.
LinuxMovieMaker$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
Make a film from your clips, photographs, titles and music.
by LinuxDoors · created September 7, 2026
A LinuxDoors AppImage Software Product
icon (.png)
Build 2 — a window that stays responsive, and picture/sound in step
Build 2 moves the frame-composing work off the thread that draws the window. Scrubbing and dragging the ruler stay smooth while ffmpeg decodes -- the window no longer freezes waiting for a frame, and only the latest position you asked for is worked on, so it cannot fall behind a fast drag. Playback composes frames ahead of the playhead into a small buffer and shows them as the clock reaches them; on a machine that cannot decode in real time the picture drops frames while the sound and the clock stay true, rather than the whole window seizing up. Picture and sound now stay together: during playback the picture is timed from the sound's own position instead of a free-running clock, which fixes the sound trailing the picture across a cut or a transition. Pressing Play from a moved playhead starts from there and no longer snaps back to the beginning -- the sound is seeked to that point once it has finished loading (an earlier seek was silently ignored), and until the sound reaches the point the picture waits rather than following the sound backwards. The export composes frames across the machine's cores (one per core, up to six; set LMM_EXPORT_WORKERS=1 for the old single-threaded path) while still writing them into ffmpeg strictly in order -- the file it produces is byte-for-byte the one the single-threaded export made. And the build now carries the Kerberos libraries Qt's media stack needs, with their version links in place, so the sound while editing works on systems that do not ship them -- LinuxDoors among them -- not only on Debian- and Ubuntu-type machines.
The preview is the film
This is where video editors usually let you down. Every frame you see while dragging the playhead about is composed by the same code that composes the exported file -- the same decoder, the same effects, the same transitions, the same titles, in the same order. There is no second, faster, rougher preview path that can disagree with what finally comes out; the export takes those frames and writes them straight into ffmpeg as raw pixels. That is a measurable claim, so it was measured: 142 frames of an exported film compared against what the preview composes at the same moments came to an average difference of 1.82 levels out of 255 -- which is H.264's own compression, not the composing. What you gain is that a fade lands where you put it, a title sits where you left it, and a transition looks in the file exactly as it looked on screen.
What is on the lanes
Pictures: video clips and photographs, one after another, each with its own length, its own start point inside the original file, its own speed from a quarter to eight times, its own volume and its own effect; a photograph gets however many seconds you say. Titles: words on the screen, over the picture or on a card of their own -- eight styles, three positions, and six ways of arriving including rolling credits. Music: one song under the whole film, with its own volume and a fade in and out. Narration: speech over the top, kept separate from the music so the two can be balanced against each other.
Effects and transitions
Twenty effects: fade in, fade out, fade both ends, black and white, sepia, old film, brighter, darker, more contrast, warmer, cooler, soft focus, pixelate, vignette, mirror, flip, rotate left, rotate right, and a slow zoom in or out -- which is what stops a photograph looking like a photograph. Sixteen transitions: crossfade, fade through black, flash through white, wipe left/right/up/down, slide in from any of the four sides, circle opening, circle closing, blinds, checkerboard and dissolve -- a transition eats into both clips rather than being added between them, so putting one in does not make the film longer than you expected. And Make it for me: one button that builds a whole film out of everything you brought in -- the clips in order, a different transition between each pair, a slow zoom on every still, an opening title with today's date, The End at the end, and the music underneath trimmed to the length of the pictures -- then change whatever you like.
Unlimited undo and redo
Every change can be taken back, and there is no ceiling on how far. That is affordable because of what a step is: the undo history holds the film described in words -- which clips, in what order, with which effects and how loud -- and not one frame of your video. A step comes to about seven hundred bytes; four hundred changes to a film came to 287 KB, and all four hundred were taken back and put forward again with everything exactly where it was. So it keeps every step by default; if you would rather it did not, Edit then Undo steps lets you stop at a number, and change your mind again at any time.
The formats
Opens -- video: mp4 mov mkv avi webm m4v mpg mpeg wmv flv ogv 3gp ts mts m2ts vob asf divx; photos: jpg jpeg png bmp gif webp tif tiff heic avif ppm pgm tga ico; sound: mp3 wav aac m4a flac ogg oga opus wma aiff aif ac3 amr. Writes: MP4 at 1080p / 720p / 480p or the size of the film itself; MP4 in H.265 for a smaller file of the same quality; WebM in VP9 for a web page; MKV in H.264; MOV in ProRes for taking into another editor; animated GIF with a palette built from the film so it does not band; and MP3 of the sound on its own. Its own file is .lmm -- a zip holding one readable JSON describing the film. It points at your video where it already lives rather than copying it, so a project file is a few kilobytes rather than a few gigabytes; if something has moved since, it says which, and everything else still works.
Being careful with your work
It will not leave half a film behind: stopping an export removes the part-written file rather than leaving something that looks like a finished film and is not. It asks before writing over anything -- both the film file and the exported movie. And it tells you what is missing before it starts: if a clip has been moved or deleted since you last opened the project, it says which ones and asks whether to go on, rather than quietly exporting several seconds of black. Light and dark themes, switched with one key, every colour pair in both themes measured against the WCAG contrast standard -- the program will tell you so itself with --check-contrast.
On the command line
LinuxMovieMaker.AppImage holiday.lmm opens that film; a bare clip.mp4 starts a film from that clip; --what-works reports what this machine can do; --check-contrast prints the contrast report; --version. --what-works is the honest one -- it says what is present on the machine and what each thing changes, including whether editing audio will be silent for want of the machine's own ffmpeg libraries (the picture, timeline and exported sound are unaffected -- those use the ffmpeg carried inside).
Running it -- nothing to install
Download the AppImage, make it executable, run it -- optionally with a .lmm project or a clip to start from. On LinuxDoors, which has no FUSE, run it the way LinuxDoors runs any AppImage: ./LinuxMovieMaker.AppImage --appimage-extract-and-run, or through linuxdoors-run-appimage, which does that for you and unpacks it once rather than on every launch. Settings live in ~/.config/LinuxMovieMaker/LinuxMovieMaker.save and are written when the program closes; deleting that file puts everything back as it started.
Written for LinuxDoors, though nothing in it is specific to LinuxDoors -- it runs on Debian- and Ubuntu-type systems, and on any other Linux distribution that can run an AppImage.
Kdenlive$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
KDE's non-linear video editor -- a multi-track timeline on top of MLT and FFmpeg.
by KDE Community · mirrored August 30, 2026
icon (.png)
Upstream download: https://kdenlive.org/download/
The timeline
Unlimited video and audio tracks, with the usual set of tools -- razor, spacer, insert and overwrite, ripple and roll. Effects and transitions are keyframable, so a blur, a crop, a colour grade or a position can move over time; compositing between tracks is a track property, not a manual step. The titler is a small vector editor of its own, with templates and keyframe animation. Audio and video scopes (waveform, vectorscope, histogram, RGB parade) dock in the window for checking exposure and levels.
Formats and staying responsive
Because it sits on FFmpeg, Kdenlive imports and exports essentially any codec and container in common use, and its render dialog ships profiles for the usual targets (MP4/H.264, WebM, ProRes, image sequences) with room to add your own. Proxy editing swaps in small stand-in clips while you cut and switches back to the originals at render time, which is what makes 4K, high-frame-rate and multi-camera projects usable on a laptop. Rendering runs in the background so you can keep working.
Mirrored, not repackaged
LinuxDoors did not build this and does not alter it. It is KDE's official stable release AppImage from download.kde.org, served here byte for byte, with its SHA-256 published so you can confirm it. The authoritative home -- source, manual, forums, bug tracker -- is kdenlive.org, linked on the card. Kdenlive is also a native LinuxDoors package (kdenlive) if you would rather it use the Qt and KDE Frameworks already on your system instead of carrying its own.
Running it -- nothing to install
Download the AppImage, mark it executable, run it. Qt, the KDE Frameworks, MLT and FFmpeg are all inside the single file. Your projects are ordinary files wherever you save them; preferences live under ~/.config. On first run Kdenlive checks for its helper tools (ffmpeg, ffplay, melt) and reports any that are missing -- in this bundle they are all included.
KDE's AppImage bundles Qt, the KDE Frameworks, MLT and FFmpeg, so it runs on most current Linux distributions with FUSE (or via ./Kdenlive.AppImage --appimage-extract). Built for x86-64.
OpenShot$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
A straightforward non-linear video editor -- trim, arrange, title and export, with a native timeline.
by The OpenShot Development Team · packaged September 1, 2026
icon (.png)
An editor built around a timeline
Add as many video and audio tracks as a project needs, then work directly on the timeline: drag to move a clip, drag its edge to trim, split at the playhead, and snap clips together. Transitions are a drag between two overlapping clips; a per-clip properties panel keyframes position, scale, rotation, opacity, volume and colour over time for straightforward motion and fades. A preview pane plays the composited result as you edit.
Native timeline in 4.0
OpenShot 4.0 drops the old browser-based timeline entirely and draws it with native Qt widgets instead. The practical effect is that zooming, scrolling and dragging are more responsive, the editor runs as a single process, and this AppImage does not have to carry a browser engine -- keeping it a fraction of the size a Chromium-backed build would be.
libopenshot and FFmpeg
The editing engine underneath the interface is libopenshot -- it composites the tracks, applies effects and keyframes, and hands frames to FFmpeg for decoding and encoding. Both are bundled here, so import and export cover the common formats (MP4/H.264, WebM/VP9, MOV, MKV, animated GIF, plus audio-only outputs) with nothing else installed. Export presets cover web, DVD, device and broadcast frame sizes, or set width, height, frame rate and bitrate by hand.
Titles and effects
OpenShot includes a title editor (SVG templates you can recolour and retype) and, where an SVG/Blender pipeline is available on the host, 3D animated titles. Clip effects include chroma key, brightness and saturation, blur, pixelate, deinterlace and a handful of others, each keyframable over the length of the clip.
Packaged by LinuxDoors, from our own build
The OpenShot project publishes its own AppImage; this is not a mirror of it. It is assembled by LinuxDoors from packages/openshot -- the same openshot-qt 4.0.0 that installs as a native LinuxDoors package -- bundled with Python 3, PySide6, Qt 6 and FFmpeg into one file. OpenShot's code is untouched; the authoritative home for source, docs and bug reports is openshot.org. If you would rather OpenShot use the Python and Qt already on your system, install the openshot package from the Packages page instead.
Running it -- nothing to install
Download the AppImage, mark it executable, run it. It carries its own glibc, so it is not tied to the host's glibc version. Your projects (.osp files) and rendered videos are ordinary files wherever you save them; OpenShot's settings and cache live under ~/.openshot_qt. On a system with FUSE it runs directly; without FUSE (including LinuxDoors itself) the bundled runtime extracts to a temp directory first -- same result, a slower first start.
The single file carries Python 3, PySide6, Qt 6 (Core/Gui/Widgets/Svg), libopenshot, libopenshot-audio, ZeroMQ, the FFmpeg libraries and its own glibc (loader + C library) -- so it does not depend on the host's glibc version and runs on x86-64 Debian 12/13, Ubuntu 22.04+ and other current distributions. Use it with FUSE, or with ./OpenShot.AppImage --appimage-extract-and-run where FUSE is absent (LinuxDoors' own kernel has no FUSE; the bundled runtime falls back to extraction automatically). First start is slower while it unpacks. Note: on some PipeWire/PulseAudio setups libopenshot cannot open an audio output for the preview player, so preview playback is silent -- this is a libopenshot limitation, it is logged rather than shown as an error, and it does not affect editing or the exported file's audio.
GIMP$0.00
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
The GNU Image Manipulation Program -- a full raster editor for photo work, painting and design.
by The GIMP Development Team · packaged September 1, 2026
icon (.png)
A full editor, not a viewer
Layers, layer groups, layer masks, channels and paths; parametric and pixel selections; a brush engine with dynamics, symmetry painting and a real clone/heal workflow; text on paths; and a filter set that covers blur, sharpen, distort, render, edge-detect, colour grading and more. GIMP 3 runs these through GEGL, so an image can be 8-, 16- or 32-bit per channel and many adjustments stay editable rather than being baked in immediately.
GEGL and babl
GEGL is the graph-based image engine underneath GIMP 3 -- every paint stroke and filter is a node in a processing graph -- and babl is the pixel-format library that lets it convert between colour models and bit depths without losing precision. Both are bundled in this AppImage, along with GIMP's own plug-ins, so filters, the colour-managed display path and file import/export all work with nothing else installed.
Scripting: Script-Fu and Python-Fu
GIMP scripts itself two ways, both working in this build: Script-Fu (a built-in Scheme console and batch interpreter -- Filters > Script-Fu > Console) and Python-Fu (the same idea in Python 3 through GObject introspection). This AppImage carries its own Python 3 and the introspection typelibs, so both run even on a system that has neither. Batch example: ./GIMP.AppImage --console -i --batch-interpreter plug-in-script-fu-eval -b '(gimp-version)' -b '(gimp-quit 0)'.
Packaged by LinuxDoors, from our own build
GIMP does not release an official AppImage. This one is assembled by LinuxDoors from packages/gimp -- the same GIMP 3.2.4 that installs as a native LinuxDoors package -- bundled with its GTK 3, GEGL, babl and Python dependencies into one file. GIMP's code is untouched; the authoritative home for source, docs and bug reports is gimp.org. If you would rather GIMP use the GTK and Python already on your system, install the gimp package from the Packages page instead.
Running it -- nothing to install
Download the AppImage, mark it executable, run it. It carries its own glibc, so it is not tied to the host's glibc version. Your images are ordinary files wherever you save them; GIMP's settings and any brushes or scripts you add live under ~/.config/GIMP. On a system with FUSE it runs directly; without FUSE (including LinuxDoors itself) the bundled runtime extracts to a temp directory first -- same result, a slower first start.
The single file carries GTK 3, GEGL, babl, the GIMP plug-ins, a Python 3 for scripting, the GObject-Introspection typelibs, and its own glibc (loader + C library) -- so it does not depend on the host's glibc version and runs on x86-64 Debian 12/13, Ubuntu 22.04+ and other current distributions. Use it with FUSE, or with ./GIMP.AppImage --appimage-extract-and-run where FUSE is absent (LinuxDoors' own kernel has no FUSE; the bundled runtime falls back to extraction automatically). First start is slower while it unpacks.
LinuxUltraOffice$9.99
The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.
A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.
Anything marked $0.00 is exactly that — free, no asterisk.
Checks or money orders sent to the LinuxDoors programmer:
To: Stanley Switaj
3438 Eden Street
Philadelphia, PA 19114
You download it first — there is no payment wall, no licence key, no trial timer. Install it, use it for real work, and if it earns a place in what you do and you like it, then pay the price shown. If it is not for you, you owe nothing.
A paid copy and an unpaid copy are the same program and behave the same way. Paying is simply you choosing to support the person who provided it, after it has proven useful to you. The software itself is the work of its upstream authors — the great programmers who wrote it; the price supports the person who packaged this build and provides it here.
A full productivity suite -- Writer, Calc and Impress -- built and rebranded for LinuxDoors OS.
by LinuxDoors · packaged September 2, 2026
A LinuxDoors AppImage Software Product
icon (.png)
Writer, Calc, Impress -- and the rest
Writer is a full word processor: styles, tables, sections, footnotes, mail merge, change tracking, a bibliography database. Calc is a real spreadsheet with pivot tables, several hundred functions, multi-sheet references, charts and a solver. Impress builds slide decks with master slides, custom animation and presenter tools. Draw (vector diagrams and simple page layout), Math (formula editor) and Base (database front end) are the same binary launched with a different flag -- pass --draw, --math or --base, or pick them from the Start Center.
Formats -- OpenDocument and Microsoft Office
The native format is OpenDocument (.odt, .ods, .odp) -- an ISO standard, plain zipped XML. It also opens and saves the Microsoft formats in daily use: .docx, .xlsx, .pptx and the older .doc / .xls / .ppt. Export to PDF is built in (File > Export as PDF, or --convert-to pdf from a script), including PDF/A for archiving. RTF, CSV, HTML and a long list of others are there too.
A LinuxDoors product
This is not a mirror of someone else's build. LinuxUltraOffice is LibreOffice source that LinuxDoors rebrands and compiles as its own package -- the splash screen, the About dialog, the window titles and the icon set all say LinuxUltraOffice. The engine, filters and file formats are LibreOffice's, unchanged, under the Mozilla Public License 2.0. The suite also installs as the native linuxultraoffice package from the Packages page, which shares the GTK already on your system instead of carrying its own.
Running it -- nothing to install
Download the AppImage, mark it executable, run it. With no argument you get the Start Center; --writer, --calc and --impress jump straight into an app. It carries its own glibc, so it is not tied to the host's glibc version. Your settings live under ~/.config/libreoffice; your documents are wherever you save them. On a system with FUSE it runs directly; without FUSE (including LinuxDoors itself) the bundled runtime extracts to a temp directory first -- same result, a slower first start.
The single file carries the whole office suite, its GTK 3 stack, and its own glibc (loader + C library), so it does not depend on the host's glibc version -- it runs on x86-64 Debian 12/13, Ubuntu 22.04+ and other current distributions, with FUSE or via ./LinuxUltraOffice.AppImage --appimage-extract-and-run where FUSE is absent (LinuxDoors' own kernel has no FUSE; the bundled runtime falls back to extraction automatically). First start is slower while it unpacks.