Darktable: [WIP] rewrite of lighttable filemanager/filmstrip

[AlicVB]

Hi all,

As some people already know, I've started a big rewrite of the lighttable filemanager.
The main idea is to have something more maintainable, without loosing current features. So it's more an internal change than anything else...

The code is here : https://github.com/AlicVB/darktable/tree/filemanager2
I've not done a PR on purpose as it's a big work that will need lot of commit revert rebase, ... so I don't want to pollute everyone mailbox...
it's currently really incomplete and WIP (but it works) so don't bother to report bugs or missing features at this point...

I just publish it here so dev (principally) can have a look and give their opinion on the approach. especially @TurboGit , @aurelienpierre and @Nilvus (this will add lot af css ;)) who have worked recently on this part of code.

Why :

• lighttable code is a mess with lot of things unused and lot of corner cases quite difficult to test/debug.
• lighttable drawing is very difficult to optimize, as all thumbnails are drawn in the same widget (even if whith @TurboGit recent change, it's quite better now)
• lot of filemanager code is duplicated in filmstrip

Idea :

• drawing each thumbnail in it's own widget, separated itself in different widgets to simplify redraw
• this implies that all parts of thumbnails can be themed with "normal" css (with the use of :hover :selected :active)
• having a "big" thumbtable widget which aglomerate all this thumbs. This widget should be flexible enough to be reused directly for filmstrip (same widget for everything)
• most of the filemanager routines should be handled inside thumbtable.
• split dt_view_image_expose in small parts, to avoid this big undebuggable blob. Especially separate the image surface creation which can be reused for preview, culling, ...
• letting lighttable view dealing with filemanager inclusion, culling and preview
• and yes, we'll drop zoomable lighttable ;)

Not sure :

• include culling mode in the new thumbtable widget (this would complexify the code, and culling operation is quite different from filemanager anyway)

Currently :

• Surprisingly the code seems to give a smaller memory footprint...
• Not surprisingly this reduce drastically cpu usage on mouse move.
• Lot of features are missing (missing icons, no keyboard use, ...)
• visual is not the same as before, but it's now just a matter of css

[TurboGit]

For the culling view I'm sure you'll find out that having a separate implementation will be better as I agree with you it is a quite different beast !

I'm really happy you got this project moving. It's an important one to ensure better support in the future. Your plan is sounds to me. Thanks!

[Nilvus]

Great to see that big and necessary rework. I'm on to work on css. I will test that soon and wait to update css. @aurelienpierre : I'm on for that. You certainly have lot of great more complicated things to work on.

[AlicVB]

Great to see that you agree to give me a lot of work ;)
So I'll go forward and post messages here when something more usable is ready . But please be patient, I expect this to takes quite big amount of time...

@Nilvus : Thanks. I'll ping you as soon as I've something for you. I just want to finish thumb drawing part first...

[upegelow]

* and yes, we'll drop zoomable lighttable ;)

Not OK for me! It needs to stay.

[AlicVB]

@upegelow :
Yes, I just see all your msgs about that point.
Sadly, the way I designed the rewrite can't handle zooming lighttable feature (or at least, I can't see how it can)
So imo, we have 2 options here :

1. drop this rewrite (not a real problem for me) => but at some point someone will have to do a big cleanup/rewrite anyway, at this part of code has become essentially a pileup of new features/fixes/fixes of fixes/... I've done quite a lot of of work in this area (so yes, I'm guilty for a part of the mess) and the number of unused/misused variables, duplicated/half-dead code parts is really huge. Sadly each time you change something, you have to add fix in another part... (just look at dt_view_expose if you want an example...)
2. replace filemanager and filmstrip by this and keep zoomable as it is => there will be specific (and encapsulated) code for preview and culling anyway, so I can propose to keep it "as it", just encapsulate it to stay "clean" in the code base. After that

Now technically, here's how filemanager drawing is implemented in my design (in case someone find a solution for implementing zoomable) :

• thumbtable is a gtkflowbox linked to a Glistmodel with a finite nb of elements (=nb of rows * nb of thumbs per rows)
• scrolling is done by adding/removing elements to the list, and the flowbox update itself automatically (a feature of gtkflowbox)
• cairo image surface of each thumb image in the list (at the exact size it should be drawn) is kept in memory

[upegelow]

2\. replace filemanager and filmstrip by this and keep zoomable as it is => there will be specific (and encapsulated) code for preview and culling anyway, so I can propose to keep it "as it", just encapsulate it to stay "clean" in the code base.

If there is really no better option that could be the way to go.

Let me explain why I am insisting to keep the zoomable light table. It is the 2D representation where images retain their surrounding (their neighborhood) and are still easy to navigate. The file manager mode lacks this very aspect. Not even the left/right neighbors remain stable if you happen to hit a line break. For me it is not usable to navigate a larger collection.

[AlicVB]

Let me explain why I am insisting to keep the zoomable light table. It is the 2D representation where images retain their surrounding (their neighborhood) and are still easy to navigate. The file manager mode lacks this very aspect. Not even the left/right neighbors remain stable if you happen to hit a line break. For me it is not usable to navigate a larger collection.

I think that I see your use case. I don't use the same workflow, but it's certainly because I mostly navigate in small collections and never change the zoom level (I use culling or full preview to see more details)

Now about the implementation :

2\. replace filemanager and filmstrip by this and keep zoomable as it is

Is not really a good idea after more thought, as that would means duplicating somehow all the drawing code if we want to have consistent look between all modes. This imply to fall back to the current "full cairo drawing and manual event handling" and all that comes with that (most of this was done by gtk and css in my implementation)

I'm not sure it's worth the pain to rewrite all this if at the end we get an as-complex/messy code :(

Let me have some days to rethink all this...

[aurelienpierre]

The way I see it is file manager and zoomable light table are the same: they are both thumbnails contained in a frame. The difference is the frame is constrained to "physical" screen bounds for the file manager, while the frame is constrained by the number of thumbs on a row for the lighttable, and then the display is clipped to the screen bounds. Both frames are displayed in a container that is as large or smaller than the inside frame.

It's just a matter of managing the inside widget vs. container width, and dealing with overflows. Putting the lighttable in a scrollable window as a container, bound to screen size, in which a widget is set to a certain size (overflowing or not), and scrolled accordingly.

I have done that in HTML/CSS in the past. Not sure if I'm clear.

[AlicVB]

The tricky part here is that you can't, for performance/memory reasons keep all the thumbs in memory, as a collection can be huge. So you need to create/remove them on the fly.
If we take the way of 1thumb = 1widget :

• For filemanager, it's not a problem as movement (scrolling) is predicable, so you just have to load next/previous thumbs and remove older ones. Then you reorder the thumb, and that's it. There's a "jump", but that's ok for the user as image as move a row up/down.
• For zooming, it's way more tricky, first for guessing which images have to be load/remove, and even more difficult for "reordering thumbs without any "jump"... That's why I don't see how to do that without drawing everything by hand in a unique drawingarea

[aurelienpierre]

How much does a widget take in memory though ?

[AlicVB]

In my test, really few. The main problem is the time spent to create all the widgets...

[aurelienpierre]

What if you create the blank list of widgets first, then fill-in the images in different threads ?

[AlicVB]

@aurelienpierre : Just retested quickly what you propose, and it seems that the gtkflowbox+glistmodel is kind of magic and take about no time for 1500 images a little more for 4000, but not really a problem ! If you do that with classic containers, it's horribly slow...

That's really great news ! I may be able to please everyone :)

[aurelienpierre]

If web browsers are able to manage that kind of feature for websites like Flickr, it would have been weird if C a toolkit couldn't. ;-)

[AlicVB]

Just to let you know : I've finally found a way to implement filemanager + filmstrip + zoomable... It's here : https://github.com/AlicVB/darktable/tree/filemanager2

Technically, it's not a widget with all the thumbs inside, as I've found that insert time explode if we reach a certain (high) number... So I've opted for a GtkLayout with only the needed thumbs inside, and some function to add/remove thumbs when needed.
It has low memory footprint and takes about no time to load.
panning and zooming in "zoomable" is ok (and it's the most difficult/time consuming part to handle...)

So we are in good shape now to go ahead :)
For the rest, no change, it's far from complete/etc... I'll post messages here as soon as there will be something to really test/review !

[TurboGit]

@AlicVB : that's great news! Keep us posted.

[junkyardsparkle]

Any chance this rewrite could include making the hover-is-selection behavior optional? :-)

[AlicVB]

little update : I've almost finished the main structure...
What works :

• display of thumbnail + infos, in filemanager/zooming/filmstrip mode.
• zoom and pan ; scrolling
• hover + selection
• double-clic to enter darkroom

What don't works :

• everything else :P (preview, culling, icons clic, offsets, ...)

@Nilvus : you can start to play with css if you want, just to see if you need something else or different... I've added some infos as a comment in the css file just for you ;) But don't invest to much time in finalizing, as things may change...

@junkyardsparkle : not sure to agree, but anyway this out of the scope of this rewrite (and believe me the scope is large enough !)

[Nilvus]

@AlicVB: no time this week. I will probably see that next week.

[AlicVB]

jfyi, after lot of (slow) work, all filmstrip features should be integrated inside the new thumbtable (and that covers big parts of filemanager features) :

• all mouse click (ratings, grouping, ...)
• most accels (ratings, selection, colorlabels, ...)
• drag and drop (not for reordering)
• saved offsets

Note that this goes slowly mainly because I fix and add consistency for many dependent features at the same time.

Next big steps are (not sorted) :

• offset change after image modifications (see #4186)
• key navigation
• reordering
• integration with culling and full preview (this basically works, but need some finetuning)

[AlicVB]

Just to share some information : after some heavy work, all the basics should be here now :) (and a little bit more !)
I still need to run some test sessions, and then I'll let you play with it...

[TurboGit]

Nice work @AlicVB, looking forward to test this !

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[AlicVB]

Thanks to all reviewers / testers, this has finally landed in master