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

First and foremost, do we have a position on AI generated code?

I see pros and cons. It was used to generate a lot/most of the agx code and provided a new module that's very nice. On the con side, it took a lot of code cleanup to get it merged. If nothing else should it be declared/tagged so that we know what we are dealing with.

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.