New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why are we quoting the clipboard contents when copying from a table view? #1244

Closed
MKleusberg opened this Issue Nov 29, 2017 · 59 comments

Comments

Projects
None yet
6 participants
@MKleusberg
Copy link
Member

MKleusberg commented Nov 29, 2017

In issue #1058 @sky5walk wrote:

Why are all entries returned in double quotes?
"xx"[TAB]"yy"[TAB]"1234"[CR][LF]
Is this to allow a TAB character within the data?
Could you add an option to drop all double quotes and just return contents [TAB] or [Comma] delimited?

I'm trying to mimic the CSV export functionality in a quicker action and on smaller selections.

Ok, let me summarize this way.
Is it risky to follow the cut/paste behavior of MS Excel?
Why add double quotes around each cell's contents?

@mgrojo already answered that it does seem we're using this to differentiate between NULL values and empty strings or something similar. Because I don't have any idea either I'll try to figure out why we're doing this and if we can change it 😄

@MKleusberg MKleusberg referenced this issue Nov 29, 2017

Closed

Copy rows + header to ClipBoard #1058

3 of 13 tasks complete

@MKleusberg MKleusberg self-assigned this Nov 29, 2017

MKleusberg added a commit that referenced this issue Nov 29, 2017

Clean up copy & paste code
Also add some TODO comments in preparation for #1244.
@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Nov 30, 2017

I'm starting to think that we add quotes only for better spreadsheet compatibility in any case. Both Excel and LibreOffice are parsing well the quoted data. But our parsing is broken both for multi-line cells and cells containing tabs.

Maybe we could get rid of the internal buffer and use another MIME type (in addition to text and HTML) for our internal copy/pasting. This way we could facilitate our parsing and at the same time set a sensible text format, compatible with spreadsheets and other applications, with quotes oly around multi-line data and data containing tabs. Maybe we could use text/csv for that as defined in RFC 4180 and reuse the CSV parsing.

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Nov 30, 2017

Another problem, that we have, is pasting from LibreCalc (5.1.6.2). An empty cell is pasted because LibreCalc adds an end of line after the last cell.

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Dec 1, 2017

From my point of view, pretty much anything which gets this working better is welcome. 😄

As a data point with RFC 4180 though... it's pretty crap for database data. There's no good way to differentiate between fields which contain (say) NULL vs an empty string. That's just the first example which I generally remember, but I'm pretty sure I've hit others before too.

So, using a different MIME type might be a really good idea. But lets pick a non-CSV thing. 😀

@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Dec 1, 2017

Yeah, we would need to choose some binary format in order to store BLOBs and NULL values as well. Both don't really work well with CSV. JSON could handle NULL values easily but as it too is a text format, storing binary data would be a pain. I'm not sure either if we can just invent our own MIME type and expect it to work on all system (pretty sure it's at least discouraged).

The alternative is to tweak the internal buffer system to work more reliably and to be used in more situations. But the coordination between internal buffer and system clipboard would always remain hack-ish.

Looks like a dilemma to me 😦

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 1, 2017

Focusing on the 90% use case:
csv cut and paste
Just double quote data whose column is defined as text. Leave all others unadorned.
I never presumed to cut or paste blobs.

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Dec 1, 2017

I think we can add quotes only around multi-line cells and cells containing tabs. I've made these changes and it seems to work well for spreadsheets (only tested with LibreCalc under Linux) and our pasting is no more broken as before.

@@ -242,11 +242,11 @@ void ExtendedTableWidget::copy(const bool withHeaders)
             QString headerText = model()->headerData(i, Qt::Horizontal, Qt::DisplayRole).toString();
             if (i != firstColumn) {
                 result.append(fieldSepText);
                 htmlResult.append("</th><th>");
             }
-            result.append(QString("\"%1\"").arg(headerText));       // TODO: Check if we need the quotes here
+            result.append(headerText);       // We don't need quotes for the column names
             htmlResult.append(headerText);
         }
         result.append(rowSepText);
         htmlResult.append("</th></tr>");
     }
@@ -277,11 +277,14 @@ void ExtendedTableWidget::copy(const bool withHeaders)
         // TODO: Do we really want to do this for the non-internal buffer case? The only case where we should definitely quote the data is when there are line breaks
         //       in the text, again for spreadsheet compatability. We also need to quote when there are tabs in the string (or replace the tabs by spaces, that's what
         //       LibreOffice seems to be doing here).
         if (!data.isNull()) {
             text.replace("\"", "\"\"");
-            result.append(QString("\"%1\"").arg(text));
+            if (text.contains("\n") || text.contains("\t"))
+                result.append(QString("\"%1\"").arg(text));
+            else
+                result.append(text);
         }
     }
 
     QMimeData *mimeData = new QMimeData;
     mimeData->setHtml(htmlResult + "</td></tr></table></body></html>");

@MKleusberg and @justinclift How do you see this for a commit?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Dec 1, 2017

To play devils advocate 😀, if we invent our own MIME type just for internal use, we could then use (say) XML (ugh!) which gives us a lot of flexibility to put whatever-the-heck-we-want in between tags. Including binary. Maybe BASE64 it to be platform neutral, but still... binary when it comes to it. eg:

<our-friggin-awesome-internal-format>
  <oh-crap-its-binary-base64>DEADBEEF</oh-crap-its-binary-base64>
</our-friggin-awesome-internal-format>
<our-friggin-awesome-internal-format>
  <null/>
</our-friggin-awesome-internal-format>
<our-friggin-awesome-internal-format>
  <what-we-have-here-is-a-string></what-we-have-here-is-a-string>
</our-friggin-awesome-internal-format>

I should probably have less alcohol before replying to stuff... 😉

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 1, 2017

Is there a new build with mgrojo's changes?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Dec 1, 2017

@MKleusberg and @justinclift How do you see this for a commit?

I'll defer to @MKleusberg for now. My head is getting back into Golang programming after a bit of a break, and my C++ is nearly non-existent now. (C++ was prior to Go for me, and my head doesn't seem to contain more than 1 language well 😦)

@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Dec 1, 2017

@mgrojo Looks good, feel free to commit that. Maybe check for tabs (and line breaks) in the header names, too, because SQLite allows tabs in column and table names. Or just change the TODO comment so it mentions that we could add this later 😉

@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Dec 1, 2017

@justinclift I thought about XML, too 😉 But it's such an annoying format to read and write that I honestly prefer the hack-ish internal buffer solution 😀

@sky5walk We definitely need to have a way to copy and paste binary data, too. The code is only in there because some people asked for it. It's also a common use case to copy entire rows or parts of them from one table to another or inside the same table and this should work for all cells no matter their content. But that's what the internal buffer is for. So that shouldn't affect the quoting problem at all 😃

mgrojo added a commit that referenced this issue Dec 1, 2017

Quote only data with end-of-lines, tabs or double-quotes
Headers are also quoted if they contain end-of-lines or tabs.

See #1244
@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Dec 1, 2017

@sky5walk you can try the next nightly build that only puts quotes around data containing end-of-line characters, tabs or quotes.

@MKleusberg Another option would be to copy always to the system clipboard, replacing binary data with BLOB or some ASCII encoding, and, at the same time, saving in the internal buffer. The way to coordinate the system clipboard and the internal buffer would be with a different and proprietary MIME format that wouldn't contain the data, but some kind of reference as if saying 'hey since you copied this data to clipboard, you can still paste your internal data'. That could be a checksum, a timestamp, sequence number or any hardcoded string (I think there will be no need for any check, but it could be used, just in case). Whenever other application writes to the clipboard, it would overwrite our MIME data (application/x-sqlitebrowser, e.g.), allowing us to copy/paste from other applications.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 2, 2017

Thanks for the new build.
Version 3.10.99 (Dec 1 2017), Qt Version 5.7.1, SQLite Version 3.21.0
Unfortunately, I see no change in behavior for either [Ctrl+C] or [Ctrl+Shift+C]?
All my numeric data is still enclosed in double quotes. :(
"1" "1" "3.0"
"2" "1" "3.0"
"3" "1" "3.0"

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Dec 2, 2017

@sky5walk I don't exactly know how and when the nightly builds are generated, but that seems to not include my change. Could you try again with the one from Dec 2?

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 2, 2017

Awesome, Dec 2nd works, but only the x86 exe?
Both [Ctrl+C] & [Ctrl+Shift+C] send to clipboard without double quotes.

x64 will not install on Windows 10 x64. Several dll write failures.
EDIT: Works fine after reboot.
(Several SQLite imageformat dll's were unreleased and could not overwrite.)

Thanks for this enhancement.
I no longer need to alter my parser for DB Browser.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 2, 2017

Ok, I just noticed the inclusion of line numbers in my clipboard data if I select all by clicking the TopLeft region of a table header?
Is this intentional or a bug?
This is super confusing, as there is suddenly data(leading line numbers, rowid) that has no column associated. But, only if you select data in a certain way.
(Note, the line numbers are highlighted in the grid view.)
My opinion is this should be in a preference:
[±] Include line numbers in clipboard captures.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 2, 2017

Also, notice an error prompt while pasting:
"The content of the clipboard is bigger than the range selected.
Do you want to insert it anyway?"
The paste operation places a Null in the next row directly under the 1st selected column.
Yet, there is no trailing Null in the clipboard.
This may be another issue, since it fails also if I double quote all individual contents.

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Dec 3, 2017

@sky5walk You've encountered the problem described in #1094. We are copying and pasting the hidden columns, including this rowid column, which is hidden. Copying hidden columns makes sense (although I have doubts) when they are pasted in the same column region. The workaround for your case is to select the first column in the horizontal header and drag to the last one. In this way you don't select the hidden rowid column.

The second issue is due to the final end-of-line that other applications place at the end of the content. We are interpreting that as a NULL field. This could be fixed, when we are able to paste always from our internal buffer. Then we can ignore this extra line when pasting from other applications.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 3, 2017

Is there a separate issue for the trailing NULL insertion?
No way this should be the default.
If the user clipboard has 2rows x 3cols, and the last element has a [NEWLINE], it should be ignored, else the paste is not symmetric.

MKleusberg added a commit that referenced this issue Dec 4, 2017

Don't treat trailing line break as NULL value when pasting from clipb…
…oard

When copying cells from a spreadsheet application an extra line break is
appended to the clipboard text. This commit adds some extra code to our
parser to remove this line break. Without this we would paste a single
NULL value into an additional line.

See issue #1244.
@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Dec 4, 2017

Thanks, @sky5walk, those are both good observations. I'm honestly surprised by how broken the copy-paste code is 😉

Both these issues should be fixed in the next nightly build. Can you check if that's improving the situation for you?

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 4, 2017

Awesome! 171205 works great.
Pastes are stable.
And, I can copy with headers [Ctrl+Shift+C] and no double quotes within a SQL result.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Dec 5, 2017

Thanks for the fix.

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Dec 6, 2017

@sky5walk Just to confirm, is this issue fully solved now? eg we're ok to close this one? 😄

@pamtbaau

This comment has been minimized.

Copy link

pamtbaau commented Jan 25, 2018

May I extend this issue a bit? Copy/paste of data has some inconsistent behaviours depending on the location.

In Data Browse panel and query results panel:

  1. Copy regular string, all goes well in all situations.
  2. Copy [{"property": "value"}] from closed cell, results in "[{""property"": ""value""}]" 😟
  3. Copy [{"property": "value"}] from cell in edit mode (in Browse Data), results in [{"property": "value"}]

In Edit Database Cell panel:

  1. Copy [{"property": "value"}], results in [{"property": "value"}]
@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Jan 25, 2018

We are still quoting strings that contains double quotes. This is our rational, directly copied from the source code:

    // Empty string is enquoted in plain text format, whilst NULL isn't
    // We also quote the data when there are line breaks in the text, again for spreadsheet compatability.
    // We also need to quote when there are tabs in the string (another option would be to replace the tabs by spaces, that's what
    // LibreOffice seems to be doing here).

I'm not convinced, though. The HTML version of the clipboard works well with LibreOffice, but the text version (Special paste -> Plain text format) leaves the quotes as we are actually copying them. What happens with Excel?

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Jan 26, 2018

From number 2. in @pamtbaau's quote above...

Copy [{"property": "value"}] from closed cell, results in "[{""property"": ""value""}]"

It kind of seems like we're adding quotes around that whole thing (then double quoting the internal quotes) when it doesn't need the outside quotes at all? Doesn't look like there are any tabs in it, and the code for doing the same thing in the edit cell seems to get it ok.

Maybe we need to treat copying-of-a-single-cell in the browse data tab slightly differently?

mgrojo added a commit that referenced this issue Feb 14, 2018

Do not escape single cell data in clipboard copy
For single cell without-headers copy it is better to not escape the text
since there isn't any gain in trying to escape quotes, end-of-lines or
tabs. Escaping should only be done for table like data for compatibility
to spreadsheets applications.

See issue #1244.
@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Feb 14, 2018

@justinclift Yes, it makes sense to treat copying-of-a-single-cell differently and never apply there any escaping, since there isn't any gain in doing that for only one cell.

@pamtbaau The next nightly build will have that improvement. Would you have some time to test it?

@mgrojo mgrojo added the enhancement label Feb 14, 2018

@pamtbaau

This comment has been minimized.

Copy link

pamtbaau commented Feb 15, 2018

The below copy scenario does not have extra quotes anymore. It seems to be fixed. Thanks @mgrojo

Copy [{"property": "value"}] from closed cell, results in "[{""property"": ""value""}]"

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Feb 16, 2018

Just to check, as I'm not 100% sure... is this considered resolved now? eg should we close this issue? 😄

@pamtbaau

This comment has been minimized.

Copy link

pamtbaau commented Feb 16, 2018

The original question still stands unresolved:

Why are we quoting the clipboard contents when copying from a table view?

When copying an entire row, cells with quotes are still quoted. So, IMHO the issue cannot be closed yet...

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Feb 16, 2018

This is the current behaviour for the text version of the clipboard: copy from one cell, copies the text as is; copy from multiple cells, escape each cell individually when it contains double quotes, end-of-lines or tab characters.

The escaping was meant for Excel compatibility (I say Excel, because OpenOffice leaves the escaped quotes). Without escaping, those characters break the data in different cells as the original.

But if we take into account that we have now the HTML version, which doesn't have these problems and that it's the default clipboard version used by Spreadsheets, the escaping of the text version is less important. I haven't removed it because I'm unsure if someone, beyond Spreadsheets, is depending on it. I'd like to hear @MKleusberg's opinion on this.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Feb 17, 2018

Ok, just tried 180217 nightly and I am now super confused by the weird copy and paste behavior?
Multiple cell copy/paste alters the internal text!?
My text cells should not be altered within the cell. I can live with a surrounding "my big text cell".
But not "my big ""text"" cell".

Mode                             Behavior
-----------------------          ---------------
Single cell copy                 ok
Single cell copy w/header        Surrounds "'s with "'s even within cell text
                                 Maybe treating "'s as a delimiter?
Multiple cell copy               Same as single cell copy w/header
Paste single multiple line text  Clips paste at 1st [CR+LF]
                                 Are newlines treated as a delimiter?
                                 I thought Tabs were the delimiter?

Example text: [CR+LF], [Tab] = \r\n, \t.
5[Tab]-999[Tab]SQL, "SELECT * FROM mydb;"[Tab]-999[Tab]SQL, "SELECT * FROM mydb[CR+LF]
WHERE x=y;"

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Feb 17, 2018

This is the expected behaviour @sky5walk.

Mode                             Behavior
-----------------------          ---------------
Single cell copy                 Do not perform any escaping
Single cell copy w/header        Whenever the cell contains double quotes, tabs or new-lines, the 
                                 entire cell is quoted in "" and whatever double quote is found is doubled
Multiple cell copy               Same as single cell copy w/header
Paste single multiple line text  Newlines are row delimiters, so the text is pasted to different lines when
                                 pasted in the table. For pasting as a single cell text, use the Cell Editor.

The algorithm to unescape the cell texts is:

  1. If the cell starts with a double quote then:
  2. Remove the initial quote
  3. Do not consider tabs and newlines as delimiters, but as regular characters
  4. Replace pairs of double quotes by a single double-quote
  5. End the cell when the final single double-quote is found, removing it from the ouput.

This is what Excel and probably other applications are doing. If we want to allow cell text with double quotes, tabs and newlines inside cell text, some escape mechanism is needed.

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Feb 20, 2018

To be honest, I do not see the logic of altering the contents of a cell beyond adding 2 surrounding double quotes.

Ex. 
[my original "stuff" cell contents] --> copy to clipboard --> ["my original "stuff" cell contents"]
Not ["my original ""stuff"" cell contents"]?

My main use of DB4S is browsing numerical data and prototyping database design.
In my opinion, cut and paste operations with complex text of more than 1 cell, is not safe.

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Jul 25, 2018

With my last commit for this issue (65c670a) the copy and paste inside the application is broken for multi-line cells. This is due to not attaching the HTML version but only the unquoted text version of the cell data. I want t fix that and a direct approach is to not differentiating the single cell case for the HTML version, but only for the text version.

But I'm starting to consider removing all the quoting altogether. I think the HTML version is already providing good compatibility with spreadsheet applications (which seems to me now the only reason to make the quoting and escaping) and it is also the mechanism for recognizing our own copies so we use use the internal buffer, so the copy is perfect inside the application. A clean text version (even though being a data-loss version) seems also the best approach for applications like plain text editors, which won't understand nor use the rich-format HTML version, but should be provided with a readable version of the data.

@justinclift @MKleusberg @chrisjlocke and users involved in this issue, any opinions on that are welcome. Is anybody depending on the quoting of the text version? How is the clipboard text version being used?

MKleusberg added a commit that referenced this issue Sep 28, 2018

Never quote cells when copying them to clipboard in text mode
This commit make sure that we never quote cells or change their contents
when copying to the text clipboard. This way the data can't be parsed
anymore without being ambigious but for these purposes we have the
internal buffer and the HTML clipboard. This makes sure that for simple
text copies (mainly that should be single cells) the data is never
changed.

This commit also uses the normal copy code for single cells unless they
are image cells. This makes sure that copying a single cell also uses
the internal buffer which in turn avoids problems when copying and
pasting single cells with line breaks in them.

See issue #1244.
@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Sep 28, 2018

I just pushed a commit which implements @mgrojo's suggestions as I understand them. We're now never quoting cells when copying them into the text clipboard and we're now using our internal buffer for single cells as well. The only exception to this is when copying a single cell which contains an image because graphics programs don't support the HTML embedded image we're creating.

I think this also answers the original question why we're quoting the clipboard contents. We only did that for two reasons:

  1. Allow pasting the data again without any losses. This was made obsolete a long time ago by the internal buffer.
  2. Allow pasting the data in spreadsheet application. This was made obsolete some time ago by the HTML clipboard.

So originally it was needed but not anymore. Also the new solutions are far superior. So I guess Manuel is right that for the text mode we can stop quoting and just copy the simple data as it is.

Anybody wants to give the new code a try? Can we close this issue then? 😄

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Sep 28, 2018

Yes, you've understood my arguments and the implementation is exactly as I expected.

Moreover, I've tested a bit and everything seems to work as expected.

@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Sep 28, 2018

@sky5walk Do you want to give tomorrow's nightly build another try? We believe it should be working as expected now - but you never know 😄

@sky5walk

This comment has been minimized.

Copy link

sky5walk commented Sep 28, 2018

Yes, will do. Thanks!

@pamtbaau

This comment has been minimized.

Copy link

pamtbaau commented Sep 28, 2018

I'll have a look at it too.

@MKleusberg

This comment has been minimized.

Copy link
Member Author

MKleusberg commented Sep 28, 2018

Cool, thanks to both of you 👍 I'm almost sure I have missed something because there were so many comments on this issue 😉

@pamtbaau

This comment has been minimized.

Copy link

pamtbaau commented Sep 29, 2018

I've compared copy/paste behaviour between nightly Sep 28 2018 and Sep 29 2018.

  • Copying multi rows/columns into text editor:
    • Sep 28 2018: Cells containing tabs are quoted, columns separated by tabs
    • Sep 29 2018: Cells containing tabs are NOT quoted, columns separated by tabs
      This is undesirable, since columns are now no longer distinguishable.
  • Copying multi rows/columns into LibreOffice/Calc:
    • Sep 28 2018: Tabs are converted into 7 spaces
    • Sep 29 2018: Tabs are converted into 7 spaces
      I think this is not desirable
  • Copy single cell in select mode into LibreOffice/Calc:
    • Sep 28 2018: Paste buffer is empty
    • Sep 29 2018: Tabs are converted into 7 spaces
      I think this is not desirable
  • Copy single cell in edit mode into LibreOffice/Calc:
    • Sep 28 2018: Tabs are split into multiple columns
    • Sep 29 2018: Tabs are split into multiple columns
      I think this is not desirable
@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Sep 29, 2018

Thanks for the report, @pamtbaau.

  • Copying multi rows/columns into text editor:

This is expected. The text version is not considered for transfering data losslessly. For that you should use the HTML version. Which is the use case that you are imagining? Do you want to parse the data from a program or only get a text version of the data for including in a text file? If you want to parse, use the HTML version from your program, it shouldn't be too hard to parse. Another option is the CSV export, which is also lossless. If you want to get a text version of the data for a human-readable file, all the quoting and escaping is counterproductive and some users have here complained. I guess we cannot satisfy all users 😄

  • Copying multi rows/columns into LibreOffice/Calc:
  • Copy single cell in select mode into LibreOffice/Calc:
  • Copy single cell in edit mode into LibreOffice/Calc:

All of these are unepexted and doesn't match with my tests with LibreOffice/Calc. It is suppose to get the HTML version and consequently all the data is inserted as a table and all the data (except non-image blobs) are preserved in the pasting. Which version are you using and how do you exactly paste? Just Ctrl+C and Ctrl+P or via the special copy menu option?

@pamtbaau

This comment has been minimized.

Copy link

pamtbaau commented Sep 29, 2018

I'm afraid I have been out of touch with SqliteBrowser for some time and may have missed something...

For that you should use the HTML version.

What is the HTML version?

In my tests, I am using SqliteBrowser (latest nightly) and copy from the "Browse Data" panel. On right-click, the only options I see are "Copy", "Copy with Headers" and "Copy as SQL". I used plain "Copy" (Ctrl+C) and paste using Ctrl+V in my tests

NB. I'm using Windows 10

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Sep 29, 2018

What is the HTML version?

The clipboard have a text and an HTML version in all the options that you've referred to, except the "Copy as SQL" where it wouldn't make sense. The receiving application is free to choose the version it prefers. LibreOffice should be using the HTML version. At least the Linux version does that. I'm now under Windows. I'll try to reproduce the problem with LibreOffice.

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Sep 29, 2018

I've tested with both Excel 2013 and LibreOffice 5.2.3.3. They are using the HTML when copying from our table browser. If you copy from the Cell Editor or from the editor mode inside the table, Qt copies a text version only. So I understand now your comments:

Tabs are split into multiple columns

This seems to be what these spreadsheets do. I think we cannot do anything about it, because even copying from notepad have that behaviour.

Tabs are converted into 7 spaces

Again, they are converting tabs to spaces when copying from other applications like a simple notepad, so we cannot do anything about it.

@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Feb 8, 2019

Closing this as we considered it solved in the new v3.11.0 release. If you consider there are still some rough edges, you are welcome to reopen this again or open a new issue as you see fit.

@mgrojo mgrojo closed this Feb 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment