darktable windows insider program

Software darktable
1

There are currently 2 problems with building darktable for Windows:

  1. Lack of developers. Most developers work on Linux. A few work on MacOS. A few of the developers run Windows, and maybe darktable for Windows, but I’m not sure there are any developers developing on Windows and thus running development builds. Which brings me to the second issue…

  2. Lack of testers. Since there are few, if any, developers running the latest builds of darktable on Windows, there isn’t much, if any, testing of the new features.

I don’t have an answer for problem 1, but I’m going to try and address problem 2 with the darktable windows insider program

What is it?

A weekly windows build of the latest development snapshot will be made available via a link from my google drive until the darktable website gets updated and then I’ll try and make it more official :slight_smile:. Windows users download it, install it alongside their production darktable build, try it out, and provide feedback to the devs.

How do I install the dev build?

Download the installer from the supplied link. Double click on the executable to run it. When prompted to remove your installed darktable click NO. When prompted to specify a directory, change the name to \Program Files\darktable37. When asked what group to install it in, use darktable37.

How do I run it?

I’ve included a zip file, at the end of the post, that contains a desktop shortcut and a darktable37.bat file to run it from a command prompt. You can also open a command prompt and run the command
"\Program Files\darktable37\bin\darktable.exe" --configdir %LOCALAPPDATA%\darktable37 --cachedir "%LOCALAPPDATA%\Microsoft\Windows\Temporary Internet Files\darktable37"

How do I provide feedback?

If you find a problem, please report it on Issues · darktable-org/darktable · GitHub. If you find an issue with a specific pull request, then open the pull request on add your comment there.

Suggestions

In your pictures directory make a darktable37 directory to keep the files processed with darktable37 separate from those processed with your production darktable.

Warnings

Development snapshots have bugs as well as new features, so it’s not recommended that you trust your photo collection to a snapshot build.

Where do I get it?

The link is https://drive.google.com/file/d/1NipUW706dbVa5Bhk02zr8sjsii1hfXef/view?usp=sharing

How do I know what changed?

Visit Pulse · darktable-org/darktable · GitHub to see a list of recent changes. If you want more information about a pull request that is merged, you can click on it to see the conversation.

darktable37.zip (1.2 KB)

15 Likes
2

Bill what about keeping the config dir inside the 3.7 install directory so if at any time you want to remove it you can just delete that directory and files don’t go in to the never land of Appdata…or maybe there is a reason for running scripts etc …

3

Do you ship with a config that disables writing XMP sidecars? If not, users may end up with 3.7 sidecars that they won’t be able to open using the stable version they have installed.

4

I don’t know if I can manipulate the settings without making code changes. That was why I recommended keeping the pictures in a darktable37 directory.

1 Like
5

Lua 5.4 is going to get added sooner or later, so at some point I’m hoping users will try scripts. There is nothing stopping a user from specifying a configdir and cachedir in the install directory

6

I prefer everything to be self-contained without data and registry crumbs when I remove the app. In terms of sidecars, it would be nice if a 37 could be appended to the name to distinguish them.

Ha ha at “insider program”. I gather this is different from the Windows Insider program proper?

7

Sorry for being a wise-ass, I missed that detail.

8

Yes, but hopefully we’ll have more success finding the bugs and driving them out than windows does :grinning_face_with_smiling_eyes:

9

You were fine. Actually I thought about the sidecars interfering, but I didn’t think the next step to disabling the writing of sidecars which I think is a good idea. I just need to look at it and see if I can do it without a code change.

My biggest fear with this is that someone will overwrite their data, though darktable does make backups.

10

I have a flatpak branch where I build master and I would like to do this as well. I think just a patch that changes the config preference would work fine for me.

11

Hi @wpferguson I do casual testing of my own development builds of darktable on Windows (I usually pull the latest master once or twice a week). One thing I find difficult is to keep up with all the changes in order to give things a timely test. Do you have any suggestion on how to alleviate that, or find out how to prioritize? I keep an eye out on the closed pull requests on GitHub, but that’s a little tedious.

12

You can have an RSS feed if you like. For example Recent Commits to darktable:master will give you an RSS feed of all darktable commits.

13

I wonder if it should probably be the other way round: Have save defaults when building darktable (sidecars off or sidecar extension “.xmp-dev”, default config directory “~/.config/darktable-dev-<shortgithash>/”) unless a “public release” flag is given in the build process.

It would make it in particular easier to deal with different revisions/branches.

1 Like
14

Many people use the master branch ‘in production’. For them, being forced to use .xmp-dev would break interoperability with other tools (such as Digikam) that also support xmp.

1 Like
15

I assume those people know what they are doing and therefore don’t shoot their feet. Therefore, they could use the “public release” flag when building their production darktable.

But the other way round, it’s not too difficult to build darktable, and a newbie or even more experienced people could accidentally run the dev darktable without command line flags such that their unbackuped database is “immediately” gone.

Both options have their pros and cons, I just wanted to give an additional perspective :smiley:.

16

Thanks for doing this. I think this is a great idea that’ll collectively save potential testers from a lot of hours compiling code individually.

1 Like
17

There seems to me to be also more fundamental issue of communication, or maybe project management. Users are left in dark about issues and possible workarounds.

It’s not affecting only windows, e.g. last year 2 releases were affected by issue with color management.
And despite it was fixed on release day of second release, package users were left in dark and with such affected release till next major one.
So I feel a bit sorry for those users which are not using master and not following github issues.

Back to windows and to another color management issue, and it is still present since 3.0.
Despite feedback was provided on github, users are left in dark about about it too.

I think some communication channel should exist for major issues, event if they are not possible to solve momentarily.
But i have no idea yet what the channel should be.

18

These are all the same problem. Windows releases will get better when we have Windows developers. Lists of known issues in each release will be maintained / communicated when someone volunteers to do that.

This is a volunteer project and if you’d like to step in and help I’m sure we’d appreciate it.

1 Like
19

Do you mind sharing your color management issue that is still present??

20

The darktable issue list is the list of existing issues. More labels are being added to the issue list to make searching easier.

For issues that occur on or close to release date, the packages are already built so it’s not feasible to fix an issue, test it, then rebuild all of the packages. The other problem is that we don’t have developers working on windows. I have no idea what the color management issue on windows is that has existed since dt 3.0. Is there an open issue?

For including known issues in the release notes, I’m not sure there is a beneficial way to do that. At release there were ~400 issues, so if we included all of that the problems would have been the longest section by far :smiley: .