Darktable: removing deprecated/broken features

[TurboGit]

I don't like to do that but we have to face it, there is almost no chance to fix the broken storage support soon, some have been broken for years.

I would like to discuss then the removing of the following storage:

• Flickr storage
• Facebook storage
• Google Photo storage

And also:

• The lighttable zoomable lighttable

This last is hard to maintain, is not 4k ready as it needs to full redraw for any action and so will become unusable on new standard definition in the coming years.

[RobbieAB]

I would be sad to see the ability to export to a web-service go, even though I don't use any of the currently available options, as the concept of "export straight to a web-gallery" is a feature I think good in principle.

That said, if they are all broken anyway, maybe it would be better to get rid of them and start over with a clean design.

[marcsitkin]

Is the problem with the export to storage with the storage providers changing spec's on their sites, or something inherent in DT? I ask because I've struggled with problems using LR with a plug in to export and synch with an account at Zenfolio. The publish works ok, but the plugin breaks everytime LR gets updated, and the synch is alway breaking.

It may be best to focus on other aspects of DT, as it's not really hard to drag and drop a folder to upload to storage. Let the storage providers do what they do, and you do what you do best.
I'd like to see some efforts made to streamline tagging, as that is the most annoying aspect of archiving images to me!

Really like the new version, I've only been using it for a week, and am very impressed. Keep up the great work, and thanks for your efforts.

[revifr]

Afaik, a large part of the problems is with changing API's and sign-in requirements (Digikam has the same trouble with web services). And, any time a provider changes the API, the external part will break _again_.

So indeed, might be best to remove those parts once and for all.

Light table zoom? huh? I didn't even know that that existed... Unless you mean the option to change the number of thumbnails per row. I'd rather not see that disappear, and the whole frame would have to be redrawn anyway on changing that

[AlicVB]

For my part (and for the part of the code I know) I'm all for removing zoomable lighttable (and no, it's not the ability to change the number of image per row, it's another layout, like culling...). In fact, I'm actually thinking and testing big rewrite of lighttable code, because it's quite a mess actually. So if you want I can take care of that.

For the external providers, if it's too hard to maintain, just drop it imho... Anyway (without knowing all the internals) I think the best would be to have an external lib for that, which can be shared between apps, but as usual it'll need someone to stand up, write and maintain it ;)

[TurboGit]

@AlicVB : Thanks for the offer, yes, please go ahead as part of your rewrite.

For the external storage it is indeed hard to maintain but the worst problem is that the providers ask for too much like having a reference domain and some DNS entries + validation. It seems that Google Photo is trying to avoid simple end-users to use the API :( At this point, and having maintained this code since some years now, I'm really fed up trying to follow all the changes.

[TurboGit]

Another point, the Piwigo storage will stay and I think dt should favor others Open Source solutions and be done with closed ones.

[RobbieAB]

If providers are being a PITA then yes, drop them.

I just feel that the ability to export directly to a web-gallery service is a nice digital asset management (DAM) feature.

[bilddateien]

regarding the zoomable light table: i never figured out how i could incorporate this feature into my workflow. I have always worked with the file manager view (zoomlevel mostly 5 per row) and used the "w" (formerly "z") key.
But: I love the new Culling Mode - great feature. Thanks for that!

Regarding web services: I suspected that the reason was the constant changes to the API as you confirmed and conditions of the services. The policy of the big players in the "social" media is solely focused on their profit - and if they need a new feature to spy on their customers even better, then the API is changed - whoever uses it should "upgrade".
So I understand it's better to have no feature than one constantly broken.

[jenshannoschwalm]

Zoomable light room? Complicates code and of no real use.

ONLY support for open source externals.

[Nilvus]

Another point, the Piwigo storage will stay and I think dt should favor others Open Source solutions and be done with closed ones.

That's just, with proprietary API that change a lot and needs complicated things to work, the best argument to remove those proprietary storage export. It would also be a point to help some people seeing for open source solutions. Using an open source software should not only mean free of charge. It's a lot more than that.

And about zoomable light mode, just throw it away. Not needed at all !

[pcanning]

I ask because I've struggled with problems using LR with a plug in to export and synch with an account at Zenfolio. The publish works ok, but the plugin breaks everytime LR gets updated, and the synch is alway breaking.

I'm very surprised to read that. I've been using Jeffrey Friedl's Zenfolio LR plugin for 10 years, have rarely had a problem (although I only use export, and haven't, and won't upgrade past LR 5.7). That said, he publishes frequent updates to deal with changes in Zenfolio or LR and to add features.

I haven't switched from LR to DT yet, but its in my plans (LR 5.7 will only work for me until I get a new camera). As a career software engineer, I'm also hoping to contribute to DT development. I'm not yet familiar with the DT development model, but would it be possible to move to more of plugin model, where support of external storage becomes the responsibility of different people than the "core" DT developers? I was expecting, for example, that I would try to add support for Zenfolio, once I start using DT as my primary image processing application.

[marcsitkin]

I've never been able to resolve the issues with the sync to published. I
did contact the author, with no response. I'm on the Adobe subscription
model, but I retired from the profession a number of years ago, and don't
really need the Adobe software as much as I did when working. I understand
that others look forward to the upgrades and new features, but I'm looking
to get off the rollercoaster ride. I'll decide once I have another month or
two with darktable under my belt. I'm also thinking about an alternative to
Zenfolio, or at least a downgrade since I no longer need the sales
features. Still looking for alternatives. Wish that Google Photos or Amazon
Prime didn't leave the shared images wide open for downloading, as either
would be possible alternatives. Am looking at Piwigo today, but finding it
a bit obscure for my level of abilities.

On Fri, Jan 3, 2020 at 2:44 PM pcanning [e-mail] wrote:

I ask because I've struggled with problems using LR with a plug in to
export and synch with an account at Zenfolio. The publish works ok, but the
plugin breaks everytime LR gets updated, and the synch is alway breaking.

I'm very surprised to read that. I've been using Jeffrey Friedl's Zenfolio
LR plugin for 10 years, have rarely had a problem (although I only use
export, and haven't, and won't upgrade past LR 5.7). That said, he
publishes frequent updates to deal with changes in Zenfolio or LR and to
add features.

I haven't switched from LR to DT yet, but its in my plans (LR 5.7 will
only work for me until I get a new camera). As a career software engineer,
I'm also hoping to contribute to DT development. I'm not yet familiar with
the DT development model, but would it be possible to move to more of
plugin model, where support of external storage becomes the responsibility
of different people than the "core" DT developers? I was expecting, for
example, that I would try to add support for Zenfolio, once I start using
DT as my primary image processing application.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/darktable-org/darktable/issues/4008?email_source=notifications&email_token=AN64KKTRGAACBMXQLUDTZFDQ36PSHA5CNFSM4KCL3GWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICBJQQ#issuecomment-570692802,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN64KKXTRC4JD4MPORGFRV3Q36PSHANCNFSM4KCL3GWA
.

--
Marc Sitkin
Marc Sitkin Photography Web Site http://marcsitkinphotography.zenfolio.com
Instagram https://www.instagram.com/marcsitkin/

[aurelienpierre]

I'm ok to remove all the mentionned parts.

I have never had use for the zoomable lighttable. As for exports outputs, they can be replaced by third-party Lua scripts that might be easier to update, if anyone is willing to step up.

[junkyardsparkle]

Externalizing the web service exports makes sense to me, at least for the ones that are obviously going to be high-maintenance moving targets forever. These are pretty commonly implemented as plugins in other software; it makes sense for them to have dedicated maintainers who actively use the particular service(s).

I don't think I've ever heard anyone expressing excitement over the zoomable lighttable.

[dtteufel]

It seems best to remove 'options' that do not work.
The Facebook option has not worked for at least 18 Months!
Users finding that 'Export to ??????' is broken may well find their confidence in the total darktable experience is diminished.

[kanyck]

I used to export my photos directly into Flickr until it got brocken. That was... well... useful. However, Flickr has changed its owner, and is changing quickly... not to the best, I feel. Anyway, the Flickr export is broken for a long time already.
So I vote for removing all that features, and also for not wasting the dev's efforts on supporting proprietary solutions/storage, because the result of all those efforts may be swiped away completely at any time.

[johnny-bit]

I'm all for @aurelienpierre suggestion - Let export to externals be lua scripts. That should open possibility to grow possible exports and since DT export don't change much, author of lua script would just have to keep up to date with external api :)

as for zoomable lighttable - between file manager and culling interface I see no usecase for zoomable lighttable :)

[wpferguson]

I think the broken exporters should be removed. I think replacing them with lua scripts is definitely possible. Since the lua scripts don't have releases or a release schedule, they can respond quicker to API changes in the provider.

[cryptomilk]

I'm a KDE guy and KDE offers kipi plugins [1] for exporting. Maybe there is something like that for Gnome/GTK

[1] https://en.wikipedia.org/wiki/KDE_Image_Plugin_Interface

[phweyland]

I never use zoomable ligthtable neither. For me it can be removed.

I'm a piwigo user but I don't use dt piwigo export. The main reason is that I cannot update a remote album. Maybe I'm alone like that, but I rarely succeed in making it all good at the first time (images and tags). Then if I remember well one cannot control the filename of images.
I prefer to load and update album from the piwigo site after having exported to files from dt. BTW that allows also to load images which do not come from dt (mobile, tablet, ...).
Even if piwigo is open source, it happens it changes its code too...
But maybe I'm still pissed off by the Lr plugin I had to buy at each Lr version ... :-)
So for me external export are a bit too basic to be useful. And probably lua is more flexible to fulfill users specific needs.

[ptilopteri]

I cannot recall ever using zoomable lighttable either.

And I am a piwigo user and also do no use the piwigo export as my only access is remote to my headless server and the export to piwigo function rarely works for me. But the export function from shotwell also fails frequently while the piwigo remote import function mostly works. emphasis on mostly, fails for 2%-3% and requires diligence.

[upegelow]

I am intensively using the zoomable light table mode. It is absolutely a key feature in darktable for me.

[aurelienpierre]

What is your use case for the zoomable lighttable @upegelow ? Perhaps it could be taken into account to redesign the file manager, instead of keeping an half-broken and redundant feature.

[upegelow]

I use it as my standard tool for navigation in big collections. Zoom out, get a quick overview, zoom into the range of images of interest, edit, zoom out again etc.
That feature has been in there for almost a decade. It worked fine and has been reliable. It is broken due the integration of a 7MB third party library less than 10 days ago.

[aurelienpierre]

which library ? It has always been crazy slow on my system, even before switching to 4K.

[upegelow]

It has been reasonably fast here, well acceptable in 2.6, even faster in 3.0. Speed has never been an issue. The integration of the lut3D branch broke it (commit eb8a2bda321fa82bd92fd211ef46e1f88a10a5bc).

[phweyland]

It is broken due the integration of a 7MB third party library less than 10 days ago.

Broken in which way ? build ? behavior ?

[MimileVadrouille]

I use it as my standard tool for navigation in big collections. Zoom out, get a quick overview, zoom into the range of images of interest, edit, zoom out again etc.
That feature has been in there for almost a decade. It worked fine and has been reliable. It is broken due the integration of a 7MB third party library less than 10 days ago.

I am a silent user of darktable since a long time also and I just use mostly (90%) the zoomable lighttable also. It s a great piece of feature. I never use the file manager which is far behind the zoomable lighttable for quick and rating options.

Generally I use it for panning/zooming, rating, add/update keywords, deleting or selecting good picts

best regards

[aurelienpierre]

Ok then, I suppose if it gets enough traction, we can keep the zoomable lighttable.

Who is willing to clean-up its code though ? That's a nasty bowl of spaghetti.

[upegelow]

Broken in which way ? build ? behavior ?

See #4114

[angryziber]

How can we export titles/descriptions to web galleries now?..
Doesn't the current version work? E.g. Google Photos new integration was even announced in release notes for 3.0

If I would discover darktable now, adding a photo service export would be the first feature I would request/contribute.

[Nilvus]

How can we export titles/descriptions to web galleries now?..
Doesn't the current version work? E.g. Google Photos new integration was even announced in release notes for 3.0

If I would discover darktable now, adding a photo service export would be the first feature I would request/contribute.

You probably didn't read correctly (or at all) why these features are removed. If you want to see them on darktable, think about asking these proprietary solutions to help software like darktable have it easily and not changing their API regularly and asking too much thing and too difficult one to access their API...

Anyway, using a free and opensource software is better to associate to some free publishing solutions like Piwigo, instead of proprietary and hard to follow solutions one for small developer community who develop on their free time...

[angryziber]

I have read the thread here, thanks. But is it really that bad?

Google Photos changed their API once during last 15 years (apart from gradually removing features from the old Picasa API). I have my own project that uses Google Photos as backend: https://github.com/angryziber/picasa-gallery

Piwigo is pretty bad in terms of the UI/UX. Even plain Google Photos albums are much better for sharing nowadays.

I would vote for removing once the code really stops working and I guess the deleted code works now as it was written very recently (at least Google Photos)... I have contributed to this code in the past and could help in future to keep it working, if any changes appear.

Or do you want somebody to maintain Lua versions of these exports now?

[parafin]

It already doesn't work:
https://github.com/darktable-org/darktable/issues/3475
https://github.com/darktable-org/darktable/issues/3970

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Please check if the master branch has fixed it since then.

[TurboGit]

Closing as clean-up done.