Version: 1.0.99 (using 4.00.66 (KDE 4.0.66 >= 20080313), compiled sources) Compiler: gcc OS: Linux (x86_64) release 2.6.22-14-generic Please make filenames fully visible in the icon view. It's currently not possible in any way to identify which is which of 2 or more files starting with a common string of more than a few characters (depending on luck, it seems like the number characters displayed is kinda random). Or as a workaround, at the very least, provide a tooltip.
I'm not sure now to which state I should set this bug-report: a) Since Sunday Dolphin provides a correct clipping for filenames -> if you've set the icons-mode to e. g. 2 lines, then the 2 lines are used in any way (so the "displaying kinda random" issue is fixed) b) Regarding filenames which still are longer: on one hand there is the statusbar where you should see the filename, on the other hand David Faure currently works on implementing tooltips in a generic way for Dolphin + Konqueror. c) The third option (which I think would be optimal) is that the icons view checks how many lines it needs itself and does an optimized layout of the height like in KDE 3. Sadly this is not supported anymore in Qt4 and requires quite some efforts and time. It's on our TODO-list, but I fear it cannot be done until KDE 4.1. Which of the options (a, b, c) would be a sufficient solution for you?
On tirsdag 01 April 2008, Peter Penz wrote: > ------- Additional Comments From peter.penz gmx at 2008-04-01 09:06 > ------- I'm not sure now to which state I should set this bug-report: > > a) Since Sunday Dolphin provides a correct clipping for filenames -> if > you've set the icons-mode to e. g. 2 lines, then the 2 lines are used in > any way (so the "displaying kinda random" issue is fixed) > > b) Regarding filenames which still are longer: on one hand there is the > statusbar where you should see the filename, on the other hand David Faure > currently works on implementing tooltips in a generic way for Dolphin + > Konqueror. > > c) The third option (which I think would be optimal) is that the icons view > checks how many lines it needs itself and does an optimized layout of the > height like in KDE 3. Sadly this is not supported anymore in Qt4 and > requires quite some efforts and time. It's on our TODO-list, but I fear it > cannot be done until KDE 4.1. > > Which of the options (a, b, c) would be a sufficient solution for you? I'll have to update to see recent improvements. for a): I haven't done any configuration, so dolphin runs with its own defaults. The selection of which part of a file name is visible appears random to me :-) for b): Tooltips would be fine, although the information bar appearently works with mouseover, with a bit of delay (btw it potentially displays information about a file in another directory, unless you fixed that;). Maybe the tooltip should just be the obscured filename if the information bar is enabled. for c) Yes, that would be the optimal reason! :-)
Hi, here's what I think: for a): It's not sufficient: I just tried in a folder with rather long file names: It's plain trial and error to find the sufficient number of lines. Maximum number of lines was limited to 5, which wasn't sufficient in my case! for b): It's not sufficient: A tooltip is like playing Memory - You have to have some kind of educated guess, and then wave your mouse pointer over the maybe right filename. for c): That's the only way to do it right! BTW, the number of icons per 'icon view line' should also be taken care of, e.g. 5 icons in a row with 12 lines of text look worse than 2 icons with 3 lines of wider text. Kind regards, Felix
What is a 'File manager' for? to me... the most important item to display in a file manager is the name of the files being managed. It is completely unacceptable to truncate the file name, especially by default. defeats the complete purpose of file manager. All you are showing then are pretty pictures, that indicate the file type. The length of the file names should be part of the sizing algorithm, if the name doesn't fit, then truncation is not an option. Make it fit. This is a straight-forward regression from 3.5.x
> Make it fit. I agree that this is a regression in comparison to 3.5.x, but the root cause is that in Qt4 the algorithm used in 3.5.x cannot get applied. So for clarification: We did not drop this on purpose; if someone has some days left to implement this algorithm in a nice way that it still works with several thousand files in a fast way, we'll add it.
Peter makes a very good point in comment #4. The purpose of a file manager is to manage files, and to do that one needs to know the name of the files. What is the URL of the Qt bug which requests that this functionality be reimplemented, as it was in KDE 3?
@Dohan: No request has been done to Trolltech yet. Our initial idea was to implement this in a custom way in KCategorizedView (which is the base class for all icon views in Dolphin). Rafael (ereslibre@kde.org) currently does an internal rewrite for KCategorizedView and hopefully we can have this feature back in KDE 4.3.
That is an acceptable workaround, but other apps may still need this and Trolltech should still be made aware of the issue. Might I suggest other approachs: 1) Variable font size: The longer the filename, the smaller the font. 2) Marque scrolling I don't like either of these ideas, but some people might like them. Thanks, Peter, I am really enjoying Dolphin now. Amazing how much progress you've made in the past year, I remember d3lphin in KDE 3 and the differences look more like 10 years of development.
Decision time for this old bug. What are we gonna do with this one, Peter? Close it and leave it as it is (i personally like the current way) since you already have the status bar and the tooltips can be enabled if one wants to see more file info and the full name. Or is you "C" option going to be implemented for KDE 4.6?
MS Windows truncates, but if the item is selected then the whole filename is shown (even if it covers part of the icon below it). That does seem to be the best-compromise solution, even if it is "copying" from Redmond.
(In reply to comment #10) > MS Windows truncates, but if the item is selected then the whole filename is > shown (even if it covers part of the icon below it). That does seem to be the > best-compromise solution, even if it is "copying" from Redmond. That would get my vote! However, i have no idea if that suggestion is currently possible in the widgets used for the icon view. If someone with more knowledge about that stuff could reply on that please.
I agree for Dotan's proposal. It is not supported by Qt but could be implemented on Dolphin-side for all views (Gwenview does something similar already, although I personally don't like there that the tooltip gets moved dynamically).
Dotan's proposal doesn't help at all if you have many similar named files in the same folder. Think of a file scheme like this (which is actually a scheme I'm using...): invoice-no_[number]-[customer]-[project]-[year]-[month].pdf Currently, with Dolphin's default settings this gets truncated to somtheing like invoice_no_123-custome... To find all invoices for a given project this is not usable. I need to switch to detail view. It doesn't help at all to see the full file name only when the file is selected or pointed to. How's about this: 1. Find those parts of the file names wich differ. Those are the important parts. 2. Truncate the common parts. 3. Truncate the differing parts as much as needed but only as much that they are still distinguishable. Sure, this is a bit more complicated, but why should we copy from Richmond if we can think of something better? Regards, Felix Am 19.09.2010 13:59, schrieb Dotan Cohen: > https://bugs.kde.org/show_bug.cgi?id=160184 > > > > > > --- Comment #10 from Dotan Cohen<kde-51 dotancohen com> 2010-09-19 13:59:27 --- > MS Windows truncates, but if the item is selected then the whole filename is > shown (even if it covers part of the icon below it). That does seem to be the > best-compromise solution, even if it is "copying" from Redmond. > >
sorry, fexpop, but that idea is not gonna make it. It's just to complex to make and probable confuses people as well. i think dotan's idea (so stealing microsoft's idea) is the best way to go.
Am 23.09.2010 17:18, schrieb Mark: > https://bugs.kde.org/show_bug.cgi?id=160184 > > > --- Comment #14 from Mark<markg85 gmail com> 2010-09-23 17:18:38 --- > sorry, fexpop, but that idea is not gonna make it. It's just to complex to make > and probable confuses people as well. > > i think dotan's idea (so stealing microsoft's idea) is the best way to go. > > Sure, my idea is too complex given that it already seems too complex to get full filenames displayed in icon view ;-) But 1. It doesn't seem very complex to me to implement a minimal version of my approach: While right now file names are truncated at the end (where they usually differ) they could much better get truncated at the beginning if there's a common string (just think of all the img*.jpg or cimg*.jpg files you usually have if you're using a digital camera). It's easy to search for patterns at the beginning of a string. 2. If it would confuse people, you can make it an option. (BTW, it's definitely not more confusing than the countless crashes I'm experiencing with Dolphin every day. In my opinion it's still in an alpha stage stability-wise. I've given up reporting crashes, it would take hours per day...) 3. While stealing Microsoft's idea might be the simplest way to go it's definitely not the *best*: It doesn't solve the bug creator's issue! It just provides a further improvement of his suggested minimal workaround. Regards, Felix
> I've given up reporting crashes, it would take hours per day... Reporting crashes would give you useful hints about the state of the bug, the root cause and how to bypass them: E.g. the most often reported crash of Dolphin currently is resulted by an issue in libdbus (https://bugs.freedesktop.org/show_bug.cgi?id=17754) and there is nothing that can been done in Dolphin to fix this. A lot of other crashes in Nepomuk/Strigi are related to this and result in crashes of Dolphin... Probably your crashes have a different root cause, but we cannot do anything against this if they don't get reported.
(In reply to comment #16) > > I've given up reporting crashes, it would take hours per day... > > Reporting crashes would give you useful hints about the state of the bug, the > root cause and how to bypass them: E.g. the most often reported crash of > Dolphin currently is resulted by an issue in libdbus > (https://bugs.freedesktop.org/show_bug.cgi?id=17754) and there is nothing that > can been done in Dolphin to fix this. A lot of other crashes in Nepomuk/Strigi > are related to this and result in crashes of Dolphin... Probably your crashes > have a different root cause, but we cannot do anything against this if they > don't get reported. erm.. what are you talking about? I guess you posted in the wrong bug.
I second this issue to be fixed. I have some certain files/folders which are suspect to the problem. When I first open Solphin, I see the file/folder fine, then when I hover over it, suddenly it clips the very last letter (which disappears). Sometimes the letter appears on a second line, sometimes it doesn't. If I press F5 once, the file/folder goes back to normal and doesn't have the problem again; until I open Dolphin again.
This issue will be fixed in Dolphin 2.0 that will get released with KDE SC 4.8. Dolphin will get a new view-engine that is capable of having dynamic item sizes.
*** Bug 191401 has been marked as a duplicate of this bug. ***
I hope that new view engine gets shared by systemsettings: Bug 262695