Bug 148572

Good point.

I think the best solution would be making thumbnails in thumbbar copies
of that in album. All info displayed there should be also shown in LT.

One can see the filename when one moves the mouse over
the thumbnail.
Also note, that you can activate the left and right side-bar to display
the image info (although this does not leave much space
for the images itself).

Concerning the display of all info as in the album view: 
If this is realized, it should be made a configurable option.
The reason is that when comparing images with the light table 
I want to have the maximum available space for the images.

Of course, it should be configurable, but I'd also suggest that there are a lot of ways to show a filename. A popup text could appear transparently overlaid on the image, or shown permanently (configurable) underneath or above the image. Etc. 

Regarding the space available, you could try a larger monitor/resolution ;-)

BTW and OT, regarding the light table, I'm slightly confused the way it seems that the thumbnails are copies of the stored files. Maybe this can be cleared up when this feature gets added?

> Concerning the display of all info as in the album view:
> If this is realized, it should be made a configurable option.
> The reason is that when comparing images with the light table
> I want to have the maximum available space for the images.


To get all(?) necessary info in thumbnail plate you need ca. 65px.
Comparing to space necessary for opening of main panels this is nothing.
You can also quickly close and open thumbnails bar.

Simon, 

Are you tried 0.9.3 release ? As Arnd said in #2, Light Table display tooltip informations over thumbbar items if you set the right option on in config dialog...

Gilles Caulier

I'm using 0.9.3, but I still think the filenames could be shown a bit more clearly  (and permanently visible) when using the light table. (Also, probably Off topic, I often have the same image on both sides, it takes some jiggling to get the right images to show in the magnification areas).

I think a clear option to show or not show filenames would be best. It could even be a simple toggle button in the light-table window.

Cheers

Simon

(In reply to comment #6)
> I'm using 0.9.3, but I still think the filenames could be shown a bit more
> clearly  (and permanently visible) when using the light table. (Also, probably
> Off topic, I often have the same image on both sides, it takes some jiggling to
> get the right images to show in the magnification areas).

At least this should be fixed with the new 0.9.4 release.

Andi

Andi,

Yes. for the moment, Thumbbar use Q3Support class (Q3ScrollView). A pure Qt4 port must be done using QScrollAera.

Gilles

Currently I'm using 0.9.5-svn (on kde 3.5.9) and the light table doesn't show the filenames when I hover over the thumbnails or the images, nor when I click on them or whatever. Only bringing up the full info panel will give me a filename.

I don't think a small single line textbox containing the name of the file in each thumbnail (perhaps half transparent, unless hovered over with the mouse) would reduce the functionality and it would make it much easier to know which image I'm dealing with.

/Simon

Simon,

Are you tried to enable tootip for thumbbar ?

Gilles Caulier

Created attachment 35525 [details]
Display image name and info in preview window

I kind of accidentally created a patch for this issue. It shows the image name and ISO sensitivity, aperture opening and exposure time in a transparent box in the upper left corner of the preview frames.

After a bit of experimenting, I found this to be a non-obtrusive and very useful feature.

Config settings are included: the user can disable this feature altogether (enabled by default), choose to display only the file name and not the other information (this is the default) and choose the amount of opacity (default is 75%).

Ok, I'm stupid...this patch shows the info in the image preview frames, not in the thumbbar, so it probably better fits to to bug 173061.
Apparently, it's time to get some sleep ;)

Pieter,

Thanks a lots for your patch.

Yes, it's not the right file to attach you patch, but #173061 is not the right one too.

Your patch touch only lighttablepreview. It's not optimum. It will be better to share your patch between lighttablepreview AND imagepreviewview. Both are based on previewwidget class. The advantage is to have your patch available on lighttable and preview mode from album gui. The best way is to create a common class based on previewwidget to include your code. Both classes lighttablepreview and imagepreviewview must be based on this new common class.

There is a bug in your patch when you zoom and pan inside preview widget, and when you use paniconwidget from the right bottom corner of preview view. Overwrited text in canvas is not cleaned properly. I will attach a screen-shot.

About setup:

- i think opacity settings is not necessary.
- Why not to separate iso speed, f-spot, and exposure options.

Excepted that setup code is fine of course. The same can be done for preview mode.

Gilles Caulier

Created attachment 35532 [details]
preview bug when panning is done with right bottom corner pan icon widget

Well, I wrote this patch because I wanted to have this information available in the light table: the file name to know what we're talking about, and these three settings to help me selecting the best picture (I often use auto bracketing). In the normal Digikam view this information (and more) is readily available from the sidebar, but in the lighttable one has to optimize for screen real estate.

So, while it can easily be adapted to be also shown on the normal image preview, I personally think that it should (of course, it's also possible to let the user make that choice). I'd love to hear what other people think about this.

Regarding this bug: I only fixed that for panning with the middle mouse button, but it can be easily extended to the other situations by subscribing to the contentsMoving signal instead of the signalContentsMovedEvent signal.

Created attachment 36007 [details]
Allow file name display in thumbnail bar

Ok, attempt 2 to help in solving this issue, this time for real ;)

There is not all that much room in the thumbnails to show the file names, so I did quite a lot of experimenting and I think the following proposal is quite satisfactory. It tries to utilize the available space as best as possible. The option to show file names can be configured by the user from the digiKam setup menu.

The first change regards the arrows that indicate which image is in which preview pane. These are currently represented by small icons in the upper left or upper right corner. This is a clear indication, but reserves quite a lot of space that can’t be used for the file name. To keep a consistent look, this space has to be reserved on every thumbnail, although an arrow is actually only displayed on two thumbnails.
This patch replaces the icons by large semitransparant arrows on the thumbnails themselves. They are black and white to provide enough contrast.
This freed space on top is now used to draw the image name. This is done semitransparently, because it is sometimes not possible to completely prevent overlapping between the thumbnail and the image name.

The next change is that this patch determines the available space on each tile for displaying the title and adjust the layout based on that. The thumbnails are all displayed on the same baseline (that is, their vertical centers are all aligned) for aesthetic reasons, but if the thumbnail sizes allow it, this baseline is shifted downwards to accommodate the file name above the image. The default baseline is vertically centered on the tile, just like it is now).
This strategy is also followed for vertical thumbnail bars.

The next change may be a bit more controversial. The patch tries to balance the thumbnail in the space between the file name on the top and the rating tool on the bottom. However, I made the use of the rating tool in the thumbnail bar to be a configurable option. When it is turned off, a bit of extra space becomes available on the bottom.
To be honest, for me this presents a great opportunity to get rid of the rating tool in the thumbnail bar :) I personally don’t use it, but I often end up accidentally rating an image when I try to select it with my mouse. So for me it gets really in the way and I would love to be able to turn it off. For me, the image name is much, much more useful to have than the rating.

On some rare occasions, the baseline can jump to another position when the thumb bar is drawn for the first time or when images are added or removed. This only happens if the baseline needs to be shifted from the vertical center, so when the thumbnails are zoomed to a very small position and the filenames are very long.
The baseline can be only correctly determined when all thumbnails are loaded. So it might happen that the thumbnails are drawn on a particular baseline, but this is adjusted as more thumbnails are loaded. On my computer (an average desktop pc), this usually happens in less than a second. This can also happen after a (vertical) resize of the thumbnail bar, because the thumbnails are loaded again.
Also, when an portrait thumbnail is added to a list of landscape thumbnails (and the baseline is shifted downward), the baseline will jump back to the center. This happens immediately. The opposite happens when the only portrait thumbnail is removed from the list.

The ability to show/hide the file name and the rating tool are not implemented in the light table classes but in its base class digikam/imagepreviewbar, which is also used for the thumbnail bar in the normal image preview and the image editor. This opens the possibility to enable these features also in these places and I really think that it should be done, but I don’t know if the config option should be made for all thumbnail bars or that it should be separated for the light bar and the album/editor view. Right now, I haven’t implemented it, but that’s a quite trivial change.

Gilles, your opinion on this patch?
I have skimmed through it and it looks all right for me, though it's a rather big patch of course.

Already done on #13... Do you read it... (:=)))

Anyway, Pieter has now an account as developper in svn... It can apply this patch himself.

Gilles

Another point of course is to port Thumbbar code to Qt4 model/view definitively...
and include this feature as well.

Gilles

Pieter,

As you start to know very well thumbbar code, Why not to work on this entry at Coding sprint event, especially to port class to pure Qt4 model/view implementation ? It's better to continue to use Qt3 support class...

Your viewpoint ?

Gilles Caulier

Gilles,

That's not a bad idea, I already looked into this issue earlier (but didn't follow through with it). I'll put in on my list.

Pieter

Pieter,

To port Thumbbar to pure Qt4 model/view, there is 2 way:

- Not really great but fast : Use QScrollArea instead Q3ScroolView as well.
- Really better, but more long to do : re-using component from Marcel about Iconview already ported to Qt4 model/view

With last one, the advantage is to factorize features. Thumbbar become an Iconview limited to a simple line/column

Gilles Caulier

Pieter, if you are interested to do a full port to model/view we should talk about that. The coding sprint would be a good occasion.

Choosing to do a proper model/view port has these advantages:
- reusing the same model already in use for the main icon view. No need to keep a private url list any more
- after some refactoring, sharing some drawing code with the delegate from main icon view
- QListView is probably sufficient for thumbbar.

Problems:
- providing a KUrl variant for showfoto and camera ui editor

*** Bug 210909 has been marked as a duplicate of this bug. ***

This is actually a wish... re-organizing the report.

Maik,

The patch about to show filename in thumbbar is obsolete since thummbar is ported to Qt4 model/view.

The patch about to show filename over perv iew canvas is interresting. There is also a bug about this topic for AlbumGUI preview canvas. So typically, this patch must be factored in parent classes to be available everywhere in preview views.

Patch must be adapted of course. It's pretty old. It include also a new specific settings for LT preview which must be moved to AlbumGUI settings to be generic.

Gilles

Relevant files which much depend of this one indirectly :

https://bugs.kde.org/show_bug.cgi?id=302559
https://bugs.kde.org/show_bug.cgi?id=336593

Gilles

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

Git commit 328d5f6d886370d2eb4a949ba1e7d7f1ad8ac39f by Gilles Caulier.
Committed on 19/05/2023 at 04:54.
Pushed by cgilles into branch 'master'.

the Light Table left and right preview show loaded filename on left and right side of status bar: improve visibility of text when a preview take focus by switch text as bold.
FIXED-IN: 8.1.0

M  +10   -1    core/utilities/lighttable/lighttableview.cpp
M  +7    -4    core/utilities/lighttable/lighttableview.h
M  +14   -0    core/utilities/lighttable/lighttablewindow.cpp
M  +3    -0    core/utilities/lighttable/lighttablewindow.h
M  +8    -8    core/utilities/lighttable/lighttablewindow_p.h
M  +6    -0    core/utilities/lighttable/lighttablewindow_setup.cpp

https://invent.kde.org/graphics/digikam/commit/328d5f6d886370d2eb4a949ba1e7d7f1ad8ac39f