Re: Review Request 111585: Don't update clipboard before cut/paste KIO operation succeeds
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111585/ --- (Updated July 20, 2013, 2:06 p.m.) Review request for kdelibs and David Faure. Changes --- Uploaded the correct patch. Description --- The attached patch fixes a bug where the contents of the clipboard are prematurely updated during a cut and paste operation. In the process I also discovered that undoing the operation does not update the clipboard either. Hence that too is fixed by this patch. Please note that this patch does not address all the cases where the content of the clipboard is not updated after a KIO operation. More specifically the clipboard content will be out of sync if the user performs the following operations: - copy/cut a file or a directory and rename it - copy/cut a file or a directory and move it - copy/cut a file or a directory and delete it. In fact there is a ticket for the copy/cut and rename file/directory scenario (bug# 134960). However, addressing these issues require a careful consideration of how to do it since delete/rename/move operations can be done outside of KDE's control. Do we simply fix the KIO jobs to handle this or do we address it the KDirWatch level so we catch all the scenarios? Probably the latter. Anyhow, that can wait until for the 134960 fix. This addresses bug 318757. http://bugs.kde.org/show_bug.cgi?id=318757 Diffs (updated) - kio/CMakeLists.txt f7a3767 kio/kio/clipboardupdater.cpp PRE-CREATION kio/kio/clipboardupdater_p.h PRE-CREATION kio/kio/fileundomanager.cpp 9f76fef kio/kio/paste.cpp ca451fb kio/tests/fileundomanagertest.h ebd02fa kio/tests/fileundomanagertest.cpp 7c1352c Diff: http://git.reviewboard.kde.org/r/111585/diff/ Testing --- Unit and manual tests. Thanks, Dawit Alemayehu
Re: Review Request 111585: Don't update clipboard before cut/paste KIO operation succeeds
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111585/#review36226
---
kio/kio/clipboardupdater.cpp
http://git.reviewboard.kde.org/r/111585/#comment26809
remove default: section (to catch missing impl of a future value in the
enum)
kio/kio/clipboardupdater_p.h
http://git.reviewboard.kde.org/r/111585/#comment26810
I'm confused. If the user presses Undo, the whole copy/move operation is
undone, not just one URL out of many URLs, right?
So I don't see why OverwriteContent doesn't work too, for the undo case?
You cut three files A,B,C from dir1, and paste them into dir2.
OverwriteContent updates the clipboard to dir2/{A,B,C}. If you then undo, the 3
files are moved from dir2 back to dir1, and therefore OverwriteContent can be
used to update the clipboard from dir2/{A,B,C} to dir1/{A,B,C}. What am I
missing?
Sounds to me like UpdateContent is there for the purpose of the other cases
you mention in the description (e.g. #134960), but that's not tested yet.
- David Faure
On July 20, 2013, 2:06 p.m., Dawit Alemayehu wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111585/
---
(Updated July 20, 2013, 2:06 p.m.)
Review request for kdelibs and David Faure.
Description
---
The attached patch fixes a bug where the contents of the clipboard are
prematurely updated during a cut and paste operation. In the process I also
discovered that undoing the operation does not update the clipboard either.
Hence that too is fixed by this patch.
Please note that this patch does not address all the cases where the content
of the clipboard is not updated after a KIO operation. More specifically the
clipboard content will be out of sync if the user performs the following
operations:
- copy/cut a file or a directory and rename it
- copy/cut a file or a directory and move it
- copy/cut a file or a directory and delete it.
In fact there is a ticket for the copy/cut and rename file/directory scenario
(bug# 134960). However, addressing these issues require a careful
consideration of how to do it since delete/rename/move operations can be done
outside of KDE's control. Do we simply fix the KIO jobs to handle this or do
we address it the KDirWatch level so we catch all the scenarios? Probably the
latter. Anyhow, that can wait until for the 134960 fix.
This addresses bug 318757.
http://bugs.kde.org/show_bug.cgi?id=318757
Diffs
-
kio/CMakeLists.txt f7a3767
kio/kio/clipboardupdater.cpp PRE-CREATION
kio/kio/clipboardupdater_p.h PRE-CREATION
kio/kio/fileundomanager.cpp 9f76fef
kio/kio/paste.cpp ca451fb
kio/tests/fileundomanagertest.h ebd02fa
kio/tests/fileundomanagertest.cpp 7c1352c
Diff: http://git.reviewboard.kde.org/r/111585/diff/
Testing
---
Unit and manual tests.
Thanks,
Dawit Alemayehu
Re: Proposal for branching policy towards KF5
On Fri, July 19, 2013 00:21:21 David Faure wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. I see this as kind of layer on top of the actual branch names (an indirection, in other words). This gives us consistency for everyone: * for contributors to a specific module, master is where new features should go * for people who compile many modules that are supposed to be working together, a logical selection layer can be selected, stable, latest-qt4, or qt5-kf5. implementation Michael: I see two ways this could be done in kdesrc-build. Either with the selection layers being defined by the projects XML and some additional magic in branch selection to allow for these new names, or with a much more low-tech solution: 3 available files to include from kdesrc-buildrc, like we did with kf5-qt5-build-include, except that these files would only contain module- options (yet another reason for that feature to exist), not actual module definitions. The user's kdesrc-buildrc would still define which module he/she wants to build, but the included file would define which branch should be used for each module (unless overriden, of course). /implementation Well there's a 3rd method as well, which is to add a separate metadata file to the kde-build-metadata repository which maps each git repository to its appropriate branch for each of the 3 categories. This is a labor-intensive task, but it's easy to centrally-manage without having to rely on many different module maintainers or core developers for each git repository to update their own metadata in projects.kde.org (assuming we can get the sysadmins to add that). In addition this would probably be easier to support for build.kde.org and the other non-kdesrc-build tools that use the current information in kde-build- metadata. We could probably significantly reduce the labor involved in maintenance by setting up defaults and then only specifying exceptions from the rule. The question will be how to group modules together. This is definitely something that would need discussion with the sysadmins and Release Team to hash out the details and any process changes that might need to happen too (e.g. adding a tool to verify all modules in kde/* are actually described for each of the 3 categories and running before a release to make sure new modules are not inadvertently left out of the metadata). I think we're getting to the point where it would be a good idea to document the metadata on our TechBase as well instead of just a README embedded within the directory. By a strange coincidence I happen to be on vacation leave so I will try to be online to discuss on IRC, but failing that we can setup a separate thread on the relevant mailing lists to hash out details. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Review Request 111585: Don't update clipboard before cut/paste KIO operation succeeds
On July 20, 2013, 9:46 p.m., David Faure wrote:
kio/kio/clipboardupdater_p.h, line 34
http://git.reviewboard.kde.org/r/111585/diff/3/?file=172590#file172590line34
I'm confused. If the user presses Undo, the whole copy/move operation
is undone, not just one URL out of many URLs, right?
So I don't see why OverwriteContent doesn't work too, for the undo case?
You cut three files A,B,C from dir1, and paste them into dir2.
OverwriteContent updates the clipboard to dir2/{A,B,C}. If you then undo,
the 3 files are moved from dir2 back to dir1, and therefore
OverwriteContent can be used to update the clipboard from dir2/{A,B,C} to
dir1/{A,B,C}. What am I missing?
Sounds to me like UpdateContent is there for the purpose of the other
cases you mention in the description (e.g. #134960), but that's not tested
yet.
Well I should have probably used a better example or elaborated more in the
documentation. The update mode is the one that should be chosen unless you are
100% certain the user did perform a cut/copy and paste operation. Currently,
the only place I know where that is the case is when KIO::pasteClipboard is
called for a move (cut+paste) operation. Otherwise, you should always use the
update mode because you do not want to inadvertently overwrite the contents of
the clipboard. I will see if I can clarify the documentation a little bit.
- Dawit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111585/#review36226
---
On July 20, 2013, 2:06 p.m., Dawit Alemayehu wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111585/
---
(Updated July 20, 2013, 2:06 p.m.)
Review request for kdelibs and David Faure.
Description
---
The attached patch fixes a bug where the contents of the clipboard are
prematurely updated during a cut and paste operation. In the process I also
discovered that undoing the operation does not update the clipboard either.
Hence that too is fixed by this patch.
Please note that this patch does not address all the cases where the content
of the clipboard is not updated after a KIO operation. More specifically the
clipboard content will be out of sync if the user performs the following
operations:
- copy/cut a file or a directory and rename it
- copy/cut a file or a directory and move it
- copy/cut a file or a directory and delete it.
In fact there is a ticket for the copy/cut and rename file/directory scenario
(bug# 134960). However, addressing these issues require a careful
consideration of how to do it since delete/rename/move operations can be done
outside of KDE's control. Do we simply fix the KIO jobs to handle this or do
we address it the KDirWatch level so we catch all the scenarios? Probably the
latter. Anyhow, that can wait until for the 134960 fix.
This addresses bug 318757.
http://bugs.kde.org/show_bug.cgi?id=318757
Diffs
-
kio/CMakeLists.txt f7a3767
kio/kio/clipboardupdater.cpp PRE-CREATION
kio/kio/clipboardupdater_p.h PRE-CREATION
kio/kio/fileundomanager.cpp 9f76fef
kio/kio/paste.cpp ca451fb
kio/tests/fileundomanagertest.h ebd02fa
kio/tests/fileundomanagertest.cpp 7c1352c
Diff: http://git.reviewboard.kde.org/r/111585/diff/
Testing
---
Unit and manual tests.
Thanks,
Dawit Alemayehu
