Why? Open an issue to discuss a topic. The scale of the topic doesn’t matter. Github is where these kinds of things are discussed, so that developers have things all in one place.
3 Likes
I dont get your comment. darktable is more than one person. It is a group of multiple developers and you are free to join in and help. There are 928 forks of darktable (go check github). Just because there is a new fork, doesnt mean the main project is doomed. AP has stated multiple times that he will continue to support the main project processing pipe and he has continue to create PRs for it. I believe the main project will continue to thrive.
I think folks are reaching too many conclusions from a new fork.
7 Likes
Perhaps, for the non-developers, it helps to know that it’s useful to fork darktable if you want to play with the code.
Using a forked version makes it easy to get all the changes in parts you are not playing with. It doesn’t mean there is yet another program out there to rival darktable.
Also, pull requests (PR’s) are requests to include code from a forked version into the main repository (look at the header of a pull request). PRs allow the darktable maintainers to go and grab the proposed change from the forked (and modified) repository. Needed, because not just anyone can modify the main dt repository (ability to modify means ability to destroy…)
As a side effect, many of those 900+ forks are probably dead/abandoned/strictly for private use of the forker.
1 Like
Ok, fair enough. But on a separate but related note, how is the decision made to include or not include a new module or upgrade, especially if someone disagrees with it? Assuming of course that it’s been fully reviewed, tested, determined stable, etc. I’m not trying to make a point, I was just wondering how that works.
First. I apologize in advance if my English is not up to par with what is desired in this conversation as it is not my native language. I am Latino and I speak Spanish. I will make use of DeepL. Ok.
I am going to state my point of view and I hope I am not creating an argument or a debate by doing so.
I understand each of the points that AP has commented in his video regarding the level of usability of the new features that have been added to darktable. Actually the program is made more complex by the addition of features that in many cases are duplicated. The collections become a nightmare because there are at least three ways to filter, by the top bar, by the same collections window and by the new filter module, not counting the recent filtering history. This far from helping makes the selection more complicated.
In addition, the icons must communicate by themselves the meaning of their function. If they are not well conceived then they are not good enough to communicate.
For years I have worked with groups of professionals, mostly developers, who have a high knowledge of design, but they are not graduate designers by profession, and every well conceived product takes the work of design professionals, this is not my idea, you live in countries where design plays a fundamental role and the design of a graphical interface for a program, is not something that should be carried by programmers (no disrespect to the excellent professionals that they are).
I understand that darktable as most of the programs created in FROSS the interface design tends to be left in the hands of the developers themselves and I understand that many do these projects in their little free time. Maybe if everyone’s effort in a coordinated way and design decisions were seen by design specialists (not programming) it would be a more coherent interface without the need to do so many forks. Of course the design of the application should go after the problem itself and the programming solutions make UI proposals are derived. Not the other way around.
The principle of functionality first and then the design must go hand in hand to provide a coherent product, which by itself communicates and encourages to be used.
4 Likes
Its the benevolent dictator model. Darktable has a maintainer, Pascal Obrey. And its his call at the end of the day. I feel like he does his best to make everyone happy and he’s done a great job at it. Its a ton of thankless work as well.
But not everyone will agree in the end, such is human nature.
6 Likes
No doubt. Configuration management is tough enough without being the adjudicator on top of that. Thanks for the info.
2 Likes
ok, so, to be sure to understand, the sole maintainer has essentially all powers to lead the product in a direction he is comfortable with, right ? Kind of a Linus Torvalds I guess ? Not saying it is bad (it is useful actually, otherwise you loose integrity of the product), just wanted to make sure I understand.
I would be very interested to hear his opinion for each point Aurelian has make.
The maintainer is the one who has the rights to merge commits to master and make a release (I think a few others have this power too, but they’re not really active anymore). So yes like Linus.
He seemed to think the changes were positive and liked them.
In my opinion Github is intimidating for non developers. At the same time - it is not an excuse not to use it.
There are few interesting points from the video that Aurelian makes
- Identify the problem then decide how to fix it.
- He - who is developer and uses Github all the time missed a feature that brought him a lot of irritation and was not able to intervene on time to alter it.
- If he (who is very knowledgeable with Github and pull requests) was unable to stay on top of it - and as per the video - developing DT is a full time job for him - how can a regular user (that is not a developer) manage to achieve something on Github? Where does the issue resides - within the end user or within the tool used?
- Despite strong objection from him - it appears that the feature was accepted by sufficient amount of people who consider it very useful and worth it to be included.
Over the last few years - the project grew a lot. While it is very welcomed by the end user - at times it was even challenging to adapt fast enough.
How is the development being approached in terms of features (I am sorry - I am not a developer - please bear with me). Is there something like a voting principal when it comes to new features or is it added because a person can develop it and adds it? Is it a collective agreement when it comes to direction or it is an individual decision? Is there something that can be learned so it can be done better?
I am hoping that there would be some good outcome out of all this. As a user - I very much appreciate the project.
What is the motivation for developers? You (developers) are creating something that is a gift - you give it freely. But at the end - what gives you joy?
I develop pictures - some people like them others don’t. But when somebody does like my pictures - the feeling is very nice.
I would assume that it is similar for you. You develop software (in addition to pictures) and give it freely - some people like it and others don’t. But I expect there must be a good feeling when you see that what you created is well accepted and appreciated.
I understand that Github is your tool - where everything happens. But if users shy away from it - there must be a reason. Perhaps pixls.us and Github can collaborate somehow - like - maybe post on pixls.us version 4.x we are planning this and that and here are the features - what do you think? Then the users can express thoughts. In my opinion - if something like this exists for every new release - users would be able to express an opinion (or vote). It is just a thought…
most of the time, they are developing tools because they themselves want to use them, so for themselves
2 Likes
I expect that but they still give it freely (open source) so there must be more (I hope there is).
Ultimately the maintainer has the final say, as the maintainer has permissions to merge changes to the main branch and make releases. Its the benevolent dictator model. Certain he listens to the feed back on github, but it is ultimately his call on what gets added or removed.
Sometimes it is and sometimes people don’t agree but the project moves forward anyway.
I don’t really know. Everything can be improved, but also design by committee is usually bad.
Github is a tool. You can use it as well, but you’ll need to learn something new and that is where most people stop.
I personally won’t ever do this kind of administrative work. I see it as needless churn. It is difficult to follow darktable’s development because there is a lot going on-- a blessing and a curse.
Gathering feedback will already make a slow process slower, if you want your voice to be heard, go to where they do their work and make your opinion known. Expecting someone to sum it up for you so you can sit back and voice your opinion while someone else does all the work is unrealistic and selfish in my personal opinion. Opinions, after all, are a dime a dozen. Action is what counts.
4 Likes
Well - this is a good summary. I appreciate the feedback. It looks like these type of dynamics on development level are something completely normal. It is good to know…
If you want to try and figure out what is going on, watch Pull requests · darktable-org/darktable · GitHub
2 Likes
well, yes and no. Pascal is the primary gatekeeper, so like Linus in that respect, but in terms of personality traits (disagreeableness?), not so much…
1 Like
The problem with GitHub for non Devs is that we might not know how, or wish to incase we break something at our end, build the development version. Thus, we cannot review New changes until they are already merged, and it is often too late to change. The only solution for this is for Devs to provide either screenshots or screen recorder of their changes. This sometimes happens, but mostly not. The GUI issues can get a lot of feedback now someone made a video about it, but seemingly too late for change.
You also have to tip toe in giving feedback, as Devs are naturally precious about their work. Even Aurelien reacted badly to filmic criticism and wouldn’t change, until he eventually saw the light and we are now on v6. Feedback on design and ideas are not as warmly welcomed for discussion as feedback on code. Now to be fair to the new collection filters dev, they were quite open in discussing design and ideas. It’s just unfortunate nobody spoke out more critically sooner. Maybe we will eventually get a collections module v6…
1 Like
There must be an option for Linux users…Bill Ferguson posts a new WIndows build each week so it is no excuse for those of us on WIndows not to evaluate things and searching the actions tab on Git will provide a running list of activity on the project…there must be a similar avenue for Linux users that can’t build a current version???
Flatpak is a good option. I have a manifest that builds master. For both darktable and R&Darktable
I’m a non-Linux guy…do you have a good reference for Flatpak’s in general… Might be nice to learn. I see so many people on different versions of Linux struggling it seems to find a way to get updated versions …maybe that is on their end… It seems simple enough to build it from the provided instructions…if you can read and cut and paste you should be 90% of the way to it but there seems to be a variety of sources and terms like flatpak and snap etc… Any tips for some basic reading on app packaging and distribution in the Linux world?? Thx…and feel free to ignore this …I can get around to it via google but if you have time to point me it would be appreciated…
Thx as always…