Bug 224511 - old name still shown in backgound after inline rename
Summary: old name still shown in backgound after inline rename
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-27 19:34 UTC by Alex Richardson
Modified: 2010-02-27 18:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot of the error (3.96 KB, image/png)
2010-01-27 19:35 UTC, Alex Richardson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Richardson 2010-01-27 19:34:57 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

Using RC2 packages from openSuSE after renaming a file with a long name to a much shorter name, the right hand side of the old name was still shown.
However I can not always reproduce it. Once it didn't happen, another time the old name was briefly shown until the file had changed position since it was now further up in the list (sorted by name)
Comment 1 Alex Richardson 2010-01-27 19:35:55 UTC
Created attachment 40297 [details]
Screenshot of the error
Comment 2 Frank Reininghaus 2010-01-28 21:27:13 UTC
I couldn't reproduce this so far, but I would assume that the cause of this bug is that some code responsible for the rendering of the file name assumes that the visualRect of the file name is the same before and after the renaming, which is not true any more since my fix for bug 217447.

I just don't know if that code is in Qt or in KFileItemDelegate, and I don't have much time to check that at the moment.
Comment 3 Frank Reininghaus 2010-02-26 15:09:01 UTC
We've changed the "Rename Inline" function slightly in KDE SC 4.4.1 and later: now the entire width of the "Name" column is used for editing. I'm pretty sure that this will also fix the problem you've found.

Please reopen this report if you hit the problem again in 4.4.1 or later. Thanks!

*** This bug has been marked as a duplicate of bug 226666 ***
Comment 4 Alex Richardson 2010-02-26 18:30:10 UTC
Just tested it on my trunk VM and it is fixed, however this is definitely not a duplicate of 226666.
Also it seems a new bug has been introduced by that change (height of rows is fixed now, but icon size still increases when zooming, but I think I should create a new bug report for that shouldn't I?
Comment 5 Frank Reininghaus 2010-02-27 18:51:13 UTC
(In reply to comment #4)
> Just tested it on my trunk VM and it is fixed, however this is definitely not a
> duplicate of 226666.

"duplicate" does not mean "the buggy behaviour is exactly the same" here, but "the code change that introduced the bugs and the code change that fixed them is the same".

> Also it seems a new bug has been introduced by that change (height of rows is
> fixed now, but icon size still increases when zooming, but I think I should
> create a new bug report for that shouldn't I?

Yes, you should. But please describe the issue in detail - I didn't quite get what the new bug is ;-)