Bug 224511

Summary:	old name still shown in backgound after inline rename
Product:	[Applications] dolphin	Reporter:	Alex Richardson <arichardson.kde>
Component:	general	Assignee:	Peter Penz <peter.penz19>
Status:	RESOLVED FIXED
Severity:	normal	CC:	frank78ac
Priority:	NOR
Version:	16.12.2
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Screenshot of the error

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 ;-)