Bug 232767 - pasted notes are blank
Summary: pasted notes are blank
Status: RESOLVED FIXED
Alias: None
Product: basket
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Slackware Linux
: NOR normal
Target Milestone: ---
Assignee: Kelvie Wong
URL:
Keywords:
: 241205 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-30 23:14 UTC by Nicholas Sushkin
Modified: 2020-03-08 15:57 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Sushkin 2010-03-30 23:14:49 UTC
Version:           2.0 beta1 (using KDE 4.2.4)
Compiler:          gcc version 4.3.3 ../gcc-4.3.3/configure --prefix=/usr --libdir=/usr/lib --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware-linux
OS:                Linux
Installed from:    Slackware Packages

I have a bunch of notes in a different stages of grouping (basically a tree of notes). I select them all by lassoing around them (drawing a rectange with a selection tool, not sure what the industry term is). Then, I click the Copy button. I go to a different basket and click the Paste button. The notes are inserted with the right hierarchy, but their content is gone. All pasted notes are blank.

Thanks
Comment 1 Scott Stubbs 2010-04-05 21:33:50 UTC
Can you do some extra steps?

Copy/Cut a note and paste it. I assume you will get is a blank note. 
Click on the blank note and you will get a cursor to put your entry. If you write *anything* by mistake, the old data will be overwritten. 
Instead of clicking on the blank (newly pasted) note, just quit basket and restart it. Now you will see that the blank note was not actually blank but it contained the pasted data.

Can you check those possibilities?
Comment 2 Nicholas Sushkin 2010-04-05 22:14:17 UTC
Confirmed that after a restart, the pasted notes contain correct text.
Comment 3 Maciej Grela 2010-04-14 23:52:21 UTC
@Comment 1:

I am experiencing the exact same issue. The notes do appear after basket restart. Does your detailed description of this workaround mean, that you know where the bug is and are able to fix it ?
Comment 4 resplin 2010-05-12 01:57:25 UTC
I see the same bug with Basket 1.0.cmake included with KDE 4.4.2 on Ubuntu Lucid Lynx. The note appears blank, but on restarting Basket it appears. Deleting the note while it is blank causes Basket to prompt if I am sure I want to delete these 8 notes.

Middle click sometimes works for pasting text into a note.
Comment 5 Robert Marmorstein 2010-05-22 01:41:27 UTC
I think I've fixed this.  The notedrag class was trying to connect a FileCopyJob to a signal which didn't exist.  However, a "Kio::CopyJob" does have that signal.  After I changed the FileCopyJob to a CopyJob, the cut/copy/paste problems went away.  

FileCopyJob and CopyJob both inherit from Kio::Job.  FileCopyJob is intended for copying/moving single files whereas CopyJob uses FileCopyJob to move entire directory structures.  I don't see any problem with using a CopyJob in this situation, even though we are probably only copying a single file most of the time.  The CopyJob class has much nicer external API (signals/slots and so forth).
Comment 6 Scott Stubbs 2010-05-27 23:29:01 UTC
@Comment#5:

So I grabbed commit 70b6bd3 from the basket/basket:master to test your fix. I can now copy and paste and have things show up without restarting. However, each note that is copy and pasted prompts me to overwrite the note.

An example of when copying and pasting note11.html it asks me (paraphrased): a newer item named note11-2.html already exists of size 0kb, the source file is note11.html of size 1.1KiB. If I let the overwrite take place then things are exactly as they should be. If I rename the file (just using the suggested name option) then a blank entry is created, and a restart doesn't have the info in it. And a new file is created called notel11-2_1.html, which basket doesn't know about (which makes sense as a side effect). Oh and if I take that newly copied file copy it I get note11-2.html and note11-3.html as the names in the dialog, makes me wonder what happened to note11-1.html.

Can you force the overwrite? And if you did, is there a chance it would encounter a nonzero file that it didn't create? I'm mostly thinking along the lines of far future sharing of baskets with different computers.

Anyway, did you encounter that prompt?

Gentoo, KDE 4.4.3.
Comment 7 Robert Marmorstein 2010-05-28 02:30:34 UTC
I'm afraid I didn't see that behavior.  I will try to duplicate it as soon as I have a stable system again (I run KDE trunk and kdelibs are pretty broken at the moment).
Comment 8 Matt Rogers 2010-06-16 13:44:14 UTC
I did see this behavior on KDE 4.4 with 70b6bd. Had a little bit of fun debugging it to see what's going on but didn't see anything yet. Will try again later.
Comment 9 Brian C. Milco 2010-10-20 09:27:45 UTC
(In reply to comment #6)
> Anyway, did you encounter that prompt?
> 
> Gentoo, KDE 4.4.3.

On my old sidux box running KDE SC 4.4.5/Qt 4.6.3 I am seeing the overwrite prompt. I recently upgraded a kubuntu machine to KDE SC 4.5.1/Qt 4.7.0 and I'm not seeing the prompt on that machine.

Is anyone still seeing this issue on 4.5.x?

Also Bug 241205 appears to be a duplicate of this one.

-Brian
Comment 10 Gregor Mi 2018-09-02 16:13:06 UTC
*** Bug 241205 has been marked as a duplicate of this bug. ***
Comment 11 Gregor Mi 2018-09-02 16:15:20 UTC
With 2.49-alpha, I cannot reproduce the behavior. Can this ticket be closed then?
Comment 12 Luigi Toscano 2018-10-24 19:55:08 UTC
(In reply to Gregor Mi from comment #11)
> With 2.49-alpha, I cannot reproduce the behavior. Can this ticket be closed
> then?

Technically Basket has not been a KDE project for few years and it is maintained externally, so this bug should be closed as UNMAINTAINED.