As I drill down into a directory tree, the folder panel gets wider in order to accommodate the deeper trees and thus the longer filenames. However, the directory names themselves remain truncated, so once I get a few levels deep it becomes impossible to identify the directory name. The attached screenshot illustrates this problem. I can't figure out any way to refresh the panel to show the full directory names. Prior to Dolphin 2.0, this would just happen automatically. I suspect this is related to the automatic scrolling (or lack there of) regression from version 2.0, which I know is planned to return at some point in the future, but I haven't seen any discussion on the directory name issue. Want to make sure it's known and will (hopefully) be addressed. Reproducible: Always
Created attachment 70560 [details] dolphin_panel_names.png
Thanks for the report, but I cannot reproduce the issue with KDE 4.8.2 - which KDE version are you using?
4.8.2. I had this problem intermittently in earlier versions of 4.8 (which is why I didn't previously file a bug - I couldn't reliably reproduce it), but since upgrading to 4.8.2 this *always* occurs. The width of visible text in the folder panel is always equal to the initial width of the panel when Dolphin is started. After that, no matter how I navigate down into different subdirectories, and even through the panel itself gets 'wider' through the use of a horizontal scrollbar, the text simply remains truncated.
Thanks for the update - I found a way to reproduce the issue now.
Git commit ef63d85d7a66777c3b8554b2d3fae031fd1e54b7 by Peter Penz. Committed on 23/04/2012 at 00:23. Pushed by ppenz into branch 'master'. Details mode: Fix wrong required column-width calculation FIXED-IN: 4.9.0 M +10 -1 dolphin/src/kitemviews/kitemlistview.cpp M +9 -6 dolphin/src/kitemviews/kstandarditemlistwidget.cpp http://commits.kde.org/kde-baseapps/ef63d85d7a66777c3b8554b2d3fae031fd1e54b7
Thanks, Peter. Always appreciate the quick response. Question, though - since this is pretty clearly a bug, with a fix that doesn't seem to be too invasive, do you think we can get this fixed in 4.8.3 as well? If there's some reason it can't be done then I'll understand, but truth be told I'd rather not wait another 3-4 months to see the fix. :-)
Although the patch does not look invasive, it is based on other rather big changes done on master since the 4.8.0 release - backporting would be quite risky because of this :-( I understand that it is still long until the 4.9 release but I think it is better for the stability if we have some beta + rc's where people test the code (if the developer is the only one that tests a fix, it is quite obvious that he can miss something: He won't test things that he did not think about during the development)