Add VS Code Dev Container Configuration

[kadykov]

Summary

This PR adds a complete VS Code Dev Container configuration for darktable development, making it easy for contributors to get started with a fully configured build environment.

What's Included

Dev Container Setup

• Dockerfile with all required and optional build dependencies pre-installed
• devcontainer.json with VS Code extensions and settings optimized for C/C++ development
• Comprehensive README documenting the development workflow

Features

• ✅ Complete build environment based on Ubuntu 24.04 LTS
• ✅ All dependencies pre-installed (GTK3, GLib, libavif, libheif, libjxl, WebP, etc.)
• ✅ Git submodules automatically initialized on container creation
• ✅ Ready-to-use C/C++ tooling (CMake Tools, clang-format, debugging support)
• ✅ AppImage build support for GUI testing on host
• ✅ Optional unit test support (documented)

Developer Benefits

• Zero setup time: Clone repo → Open in container → Start building
• Consistent environment: All developers use the same toolchain and dependencies
• No host pollution: All build tools and dependencies isolated in container
• Cross-platform: Works on Windows, macOS, and Linux hosts

Usage

1. Install Docker and VS Code with Dev Containers extension
2. Open the repository in VS Code
3. Click "Reopen in Container" when prompted
4. Wait for container build (~5-10 minutes first time)
5. Start building: ./build.sh --prefix /tmp/dt --build-type RelWithDebInfo

Scope

This devcontainer is focused on:

• Building darktable from source
• Creating AppImages for testing
• Debugging with GDB

It does NOT include:

• X11/GUI support inside container (use AppImage on host instead)
• System installation workflows (not needed for development)

Testing

I have verified that this configuration successfully:

• ✅ Builds darktable from source
• ✅ Creates working AppImage files
• ✅ Runs unit tests (with optional libcmocka-dev installation)
• ✅ Works with all VS Code C/C++ development features

Documentation

Complete documentation is provided in .devcontainer/README.md covering:

• Quick start guide
• Build instructions
• AppImage creation workflow
• Troubleshooting common issues
• Optional unit test setup

Files Changed

.devcontainer/
├── devcontainer.json    # Container configuration
├── Dockerfile           # Build environment with all dependencies
└── README.md            # Complete documentation

Notes

• Container runs as user vscode (UID 1000) for proper file permissions
• Git submodules are initialized automatically via postCreateCommand
• Build artifacts are stored in build/ directory
• AppImages can be run directly on host if workspace is mounted

---

This configuration should make it significantly easier for new contributors to start working on darktable without spending time on environment setup.

[Copilot]

Pull Request Overview

This PR introduces a complete VS Code Dev Container configuration for darktable development, enabling contributors to start building immediately without manual environment setup. The configuration provides a fully-equipped Ubuntu 24.04-based container with all build dependencies, optimized VS Code settings, and comprehensive documentation.

Key Changes:

• Added containerized development environment with pre-installed build dependencies and tools
• Configured VS Code with C/C++ development extensions and appropriate settings
• Provided complete documentation covering build workflows, AppImage creation, and troubleshooting

Reviewed Changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
.devcontainer/devcontainer.json	Configures the dev container with build context, VS Code extensions, and automatic git submodule initialization
.devcontainer/Dockerfile	Defines Ubuntu 24.04 base image with all required and optional darktable build dependencies
.devcontainer/README.md	Provides comprehensive documentation for building, testing, and troubleshooting in the dev container

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[TurboGit]

Sounds like a nice contribution. I'm not expert on this and so I'd like another dev using VS Code (yeah I'm an Emacs user) to test.

[wpferguson]

I have some thoughts and questions

EDIT: I removed my questions about AI generated code because I realized, too late, that it wasn't well worded and conveyed the wrong message. I'll address it in a issue and hopefully state it better that I did here.

Zero setup time: Clone repo → Open in container → Start building

How long does it take to compile darktable in a container? On a windows VM with 4 cores it takes 30+ minutes for a full build.

Consistent environment: All developers use the same toolchain and dependencies

No host pollution: All build tools and dependencies isolated in container

The developers are currently on a lot of different systems using the tools they've come to know and love (even Emacs 😛 ). The varied environments allow bugs that only show up on one or two environments to be caught quickly. Building in a walled garden only ensures that you can build in a walled garden.

Creating AppImages for testing

Currently the appimage is built from code tested on a variety of systems and we still run into bugs that are appimage specific. So, this may help drive out some of those bugs. However, appimage is another "walled garden" and doesn't guarantee that code that runs in the appimage is bug free when compiled and run on different operating systems/versions.

---

I'm guessing that VS Code will do incremental compiling. I've been bitten many times by incremental compiles that work but fail when built from the top. Just a caution.

---

Overall I think this could be a good thing and maybe bring some more developers into the mix, with the hope that we can finally get some windows developers. But, as I'm looking up at the CI runs I notice that it takes 5 or 6 minutes on Linux/MacOS and it's over an hour on Windows and still going

[kadykov]

@wpferguson Thank you for the detailed feedback! Let me address each point:

AI-Generated Code

I want to be transparent: I used AI assistance (GitHub Copilot) during development, but with careful human oversight. The workflow was:

1. AI suggests code/structure
2. I manually review and test everything
3. Multiple iterations and corrections based on actual testing
4. All functionality verified before submission

This wasn't a one-shot AI generation - it involved significant trial, error, and manual refinement. The AI helped me navigate the codebase faster as a new contributor, but all decisions and validation were human-driven.

I'm happy to add a note in the PR if you have guidelines for AI-assisted contributions.

Build Time in Container

On my machine (ThinkPad T14 Gen 1, AMD Ryzen 5 Pro 4650U, 40 GB RAM, SSD):

• Full clean build: < 4 minutes
• AppImage creation: < 5 minutes (includes clean build + packaging)

This is with all CPU cores available to Docker. Performance will vary based on:

• Host CPU/RAM
• Docker resource allocation
• Whether using WSL2 on Windows (adds overhead)

Incremental builds are significantly faster, as VS Code/CMake Tools handle this well.

"Walled Garden" Concerns - Valid Point!

I completely agree that diverse development environments catch more bugs. This devcontainer is not intended to replace existing development workflows. It's an additional option for:

1. Immutable Linux users (Fedora Silverblue, Bluefin, etc.) - For users like me on Bluefin, installing build dependencies on the host is discouraged/difficult. Devcontainers are the recommended development approach for these systems.

2. Quick contribution testing - New contributors can verify their changes compile without full environment setup

3. CI/local parity - Approximate the Ubuntu-based CI environment locally

4. Documentation - Having a working reference environment helps onboard contributors

This is a supplementary tool, not a replacement for native builds on varied systems.

Scope and Limitations

The devcontainer is intentionally limited:

• ✅ Build verification
• ✅ CLI testing
• ✅ AppImage creation (for GUI testing on host)
• ❌ No X11/GUI in container
• ❌ No system installation workflow
• ❌ On Windows: builds Linux binaries (not Windows binaries)

Windows developers would still need native Windows builds - this devcontainer doesn't help with Windows-specific development.

Incremental Build Concerns

Good point! The documentation should emphasize clean builds when testing. I can add a note about this in the README.

Editor Support

While this is VS Code-focused, devcontainers are actually editor-agnostic:

• Emacs: Supported via devcontainer.el package
• Vim/Neovim: Can connect to running containers
• Any editor: Can use the container via devcontainer CLI

The .devcontainer/ configuration works with any tool that supports the spec.

CI Windows Build Time

Regarding the Windows CI taking over an hour: I believe this is unrelated to this PR.

The only file modified outside .devcontainer/ was .gitignore (to ignore AppDir/ build artifact). The .gitignore change cannot affect build time.

The devcontainer files (.devcontainer/*) are not used by the CI build process - they're purely local development tooling. CMake and the build scripts don't read or depend on them. This appears to be a pre-existing Windows CI performance issue that coincidentally appeared on this PR.

Suggestion: Re-trigger the Windows CI job to see if it's a transient issue.

Summary

This devcontainer is:

• An optional tool for specific use cases (immutable systems, quick testing)
• Not a replacement for diverse development environments
• Complementary to existing workflows
• Most useful for Linux users on immutable distros and new contributors

It's meant to lower the barrier to entry while preserving the value of testing on varied real-world systems. Existing developers can continue using their preferred native setups.

---

Happy to make adjustments based on project preferences! Let me know if you'd like any changes to scope or documentation.

[github-actions]

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[github-actions]

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[github-actions]

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[github-actions]

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[wpferguson]

Is running darktable in a container really feasible/advisable for users based on darktable's resource requirements (memory, hardware acceleration, etc)?

Do we want to support another platform? If someone downstream wants to provide darktable as a container and support it, then that's fine. I'm not sure that we want to take that on, especially if the user experience isn't good.

[da-phil]

Is running darktable in a container really feasible/advisable for users based on darktable's resource requirements (memory, hardware acceleration, etc)?

Yes, that would work too, but I wouldn't bother about using such a docker image as a run-time environment, we have our AppImages for such a use-case.
I'd rather consider it a develop / build-time environment, which is the single-source of truth / reference for build-time dependencies and would work across Linux & MacOS, probably not on Windows since docker is not supported there yet.

This would also solve the dependency duplication across our CI pipelines:

• https://github.com/da-phil/darktable/blob/master/.github/workflows/ci.yml
• https://github.com/da-phil/darktable/blob/master/.github/workflows/nightly.yml

It's easy that drift can happen between those files, build guidelines and README files which talk about build-time dependencies across all supported operating systems.

[wpferguson]

nothing in this PR changes their workflow.

Until CI running on a dockerfile has a problem that can't be reproduced outside of the dockerfile.

[da-phil]

nothing in this PR changes their workflow.

Until CI running on a dockerfile has a problem that can't be reproduced outside of the dockerfile.

What are your concerns concretely?
Given that the ci + docker solution is used in most software projects these days I wouldn't expect too many surprises, it's not some experimental or exotic build pipeline which is known to be problematic. The opposite is true in my professional experience: not having an isolated environment for reproducible builds, the so-called "works on my machine" problem.
Unless there is an actual problem with that ci setup which needs to be fixed like every other ci issue.

[wpferguson]

#21911

Current master is almost unusable for any serious work. The UI sometimes (rarely) displays the correct cursor that corresponds with the operation you are performing. Randomly when switching to the next image in darkroom view the image switches, loads the new image, then jumps back to the previous image and resets it. If you return to lighttable the next image is the one that shows selected, not the current image which is the one that got reset. It's so bad that I've written tools to clean up the aftermath quickly so that I can get some work done.

All the UI problems above are code that was written by AI, compiles fine, passes CI and doesn't work because it wasn't thoroughly tested by the developer. So now it's up to the devs to TEST the code, write up the problems, and then retest the possibly tested fixes. In the meantime, the stuff we were working on sits by the wayside.

I don't know how much a dockerfile version of darktable is capable of but I suspect it is far less than darktable running natively, so testing by the dev will necessarily be limited and incomplete leading to more situations as I described above.

CI only tests that darktable will compile and run, and the IOP modules produce a given result for a given input. It doesn't test to make sure darktable actually works.

[da-phil]

@wpferguson all what you wrote above is not wrong, I would agree with most of it,but it is a tangent to the discussion about how helpful a reference build environment for reproducible builds is. I think we all acknowledge the power of diversity of native build environments to catch issues on all possible Linux distros with different library versions, this is not going away once we have such a reference build environment.

Turns out in #21911 that @TurboGit faced an issue with his native build environment, if we already had this docker container with the reference build environment in place, he could just easily pick up work and not wait until his local build environment gets fixed. Another reason for having such a reference build environment.

[da-phil]

Btw. @kadykov I'm sorry that I haven't resolved the previous review comments, github simply does not let me do it...

[kadykov]

Two notable changes:

Tiers merged into two options. The three-tier structure (Docker CLI / devcontainer CLI / IDE) was replaced by two options: Docker CLI and Dev Container. The old Tier 2 and Tier 3 were the same underlying thing — both use devcontainer.json and the same container — so splitting them was more or less artificial. The new structure makes it clearer: if you want raw Docker control, use Option 1; if you want IDE integration, use Option 2. The question "do I need to install the devcontainer CLI?" is now answered within the Option 2 section: only if you're not using VS Code or JetBrains.

build-docker.yml added. This workflow builds the image and publishes it to GHCR automatically whenever Dockerfile changes on master — so the image stays in sync with the Dockerfile without any manual steps, and only triggers on actual changes to the Dockerfile (not on every commit to the repository).

The image won't exist in GHCR until this PR merges. Once it does, the first build-docker.yml run will publish it (the Dockerfile being added to master counts as a change to the paths filter). This is deliberate: a follow-up PR to refactor ci.yml to use the pre-built image can then be properly tested against a live GHCR image before anyone has to decide whether to merge it. That makes the CI refactoring PR much less of a leap of faith for maintainers.

[da-phil]

The CI dependencies were updated when my PR (#21420) got merged, I think you need to update the docker image.

[kadykov]

The CI dependencies were updated when my PR (#21420) got merged, I think you need to update the docker image.

I have updated the Dockerfile in 6f54f8b and speed up package installation with eatmydata as it is used in the CI workflow.

[da-phil]

Look good for me now, thank you for the work!

[da-phil]

@TurboGit I think the work is complete for this PR, a follow-up PR (#21909) is already created to finish integration of the docker image into our github ci.

[kadykov]

@da-phil Thank you for reviewing this pull request and for your great suggestions.

Also, I would like to thank everybody who contributed to the discussion of this pull request. I agree with @da-phil that this pull request is complete now and could be merged. We can continue work and discussion on the CI refactoring on the follow-up pull request.

[TurboGit]

Thanks, I'll see if I find time to experiment with this at some point.