Beta testers needed

[eschwartz]

Kovid -- I know I've seen the same error myself, unpredictably so. My gut feeling is that this always happened when it coincided with a plugin update notification.

It happened before this release cycle, so it should be unrelated to the beta... the only other thing I can think of is that I hacked calibre.constants.numeric_version to append two strings (the first being the git describe commit count, the second being the git describe revision hash). But I don't see where that would ever matter.

[kovidgoyal]

Originally Posted by eschwartz

Kovid -- I know I've seen the same error myself, unpredictably so. My gut feeling is that this always happened when it coincided with a plugin update notification.

Well this should take care of it: https://github.com/kovidgoyal/calibr...178b3303987b6b

[ilovejedd]

Originally Posted by kovidgoyal

@ilovejedd: I tried pasting the provided HTML into the comments field for a book (source view of edit metadata dialog) then clicked OK. Then tried opening the edit metadata dialog again, there were no extra <br>s. Can you provide some info on how you are getting them?

Data was extracted to a couple of custom columns from plain TXT using full text search in the MultiColumnSearch plugin and copied to the comments field using bulk edit metadata search & replace.

I tried removing the excess <br> tags using bulk s&r and it looks like the raw field is actually as follows (no <p class="description"></p> encapsulating the html code):

Published: 2016-10-31 Updated: 2019-02-03 Chapters: 71/? Words: 171444
<br>
<br><b>Summary</b>
<br>"But you, Lord Snow, you'll be fighting their battles forever." Ser Alliser Thorne
<br>
<br>Every time he died his last in that life he awoke again in another at the exact moment of Ghost's birth.

[kovidgoyal]

At which step is it getting duplicated? During extraction from the original column by the plugin or during search and replace?

[ilovejedd]

Originally Posted by kovidgoyal

At which step is it getting duplicated? During extraction from the original column by the plugin or during search and replace?

Neither.

Viewing in the "Book details" window show extra line spacing in comments and when opening the book record in "Edit metadata individually", the <br> tags get duplicated.

If I click "Cancel" in the "Edit Metadata" (individual) dialog/window, the actual comments code remains unchanged (no <p class="description"></p>; <br> tags not duplicated) as verified with template tester: {comments}.

Again, I don't actually have new line characters in comments. I just added those in my earlier posts for readability to more easily show the duplication. The actual comments field is as follows:

Published: 2016-10-31 Updated: 2019-02-03 Chapters: 71/? Words: 171444<br><br><b>Summary</b><br>"But you, Lord Snow, you'll be fighting their battles forever." Ser Alliser Thorne<br><br>Every time he died his last in that life he awoke again in another at the exact moment of Ghost's birth.

[ilovejedd]

P.S. I've done some more tests and I believe the duplication only happens when the comments field doesn't begin with an HTML tag. If I do a bulk S&R so it's bounded by <div></div> or <p></p>, it displays properly.

Search:
^(.*)$

Replace:
<div>\1</div>

[BetterRed]

FWIW: when using the long text editor, if I type untagged text at the top the HTML tab and save it, the long text editor will wrap the entire thing in <div>...</div> tags. I know this because I've done it inadvertently and then had to redo in the WYSIWYG tab

Is untagged text even valid HTML? If not the problem lies with what/who created it.

BR

[ilovejedd]

Originally Posted by BetterRed

FWIW: when using the long text editor, if I type untagged text at the top the HTML tab and save it, the long text editor will wrap the entire thing in <div>...</div> tags. I know this because I've done it inadvertently and then had to redo in the WYSIWYG tab

Is untagged text even valid HTML? If not the problem lies with what/who created it.

These are all HTML snippets. Strictly speaking, none of these are valid HTML.

I can easily add <div> tags to comments using bulk s&r. That said, this is still a a bug in the beta that's not present in the current stable version.

[BetterRed]

If I type untagged text at the top of an HTML snippet and save it, the beta behaves exactly the same as the current release - wraps the whole enchilada in div tags.

IMO MCS should be changed to do the same thing as the long text editor when it saves HTML data - maybe it could even invoke the same code.

BR

[ilovejedd]

Originally Posted by BetterRed

If I type untagged text at the top of an HTML snippet and save it, the beta behaves exactly the same as the current release - wraps the whole enchilada in div tags.

IMO MCS should be changed to do the same thing as the long text editor when it saves HTML data - maybe it could even invoke the same code.

Nah, MCS is fine the way it is. Note, it's extracting data from plain TXT so no HTML code to speak of. It really shouldn't be inserting stuff into regex query results that the user didn't ask for.

I rarely ever use the individual "Edit metadata" dialog. I always bulk edit like 100 or so records at the same time. I just noticed that as seen in the attachments in post 35, I was getting extra line spacing in the comments in the book detail window when previous versions never used to do that.

If the comments field is required to begin with HTML tags, then it's the bulk s&r that doesn't automatically add the <div> tags. Although considering bulk s&r may be used to intentionally strip HTML code, that's probably just good behavior. In any case, easy enough to bulk add the tags myself if Kovid decides this change from the older versions is intended behavior.

[kovidgoyal]

I have uploaded a new beta with fixes for all remaining issues.

@ilovejedd: I could not replicate your issue, but I have added a fix nonetheless, on the basis that it is most likely caused by <br> becoming <br></br>

[ilovejedd]

Originally Posted by kovidgoyal

@ilovejedd: I could not replicate your issue, but I have added a fix nonetheless, on the basis that it is most likely caused by <br> becoming <br></br>

Yep, that fixed it.

[PandathePanda]

Imported a few pd books this morning and found this on the terminal.

kdialog: /Downloads/calibre-3.40.4-x86_64/lib/libQt5Core.so.5: version `Qt_5.9' not found (required by /usr/lib/x86_64-linux-gnu/libKF5Auth.so.5)
Traceback (most recent call last):
File "site-packages/calibre/gui2/linux_file_dialogs.py", line 318, in looped
File "site-packages/calibre/gui2/linux_file_dialogs.py", line 306, in r
File "site-packages/calibre/gui2/linux_file_dialogs.py", line 155, in kdialog_choose_dir
File "site-packages/calibre/gui2/linux_file_dialogs.py", line 135, in kde_cmd
File "site-packages/calibre/gui2/linux_file_dialogs.py", line 128, in kdialog_supports_desktopfile
File "subprocess.py", line 223, in check_output
CalledProcessError: Command '[u'kdialog', u'--help']' returned non-zero exit status 1

the error is weird as libQt5Core.so.5 is installed in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.

I'm on Kubuntu 18.04.2 and Qt version is 5.9.5+dfsg-0ubuntu2

[PandathePanda]

Hi another thing I noticed, the beta don't see soupsieve.

this error pops up wen I ran FanFicFare today:

Unknown

Cannot execute CSS selectors because the soupsieve package is not installed.

But this is when I run pip:

Requirement already satisfied: soupsieve in /home/user/.local/lib/python3.6/site-packages

&

Requirement already satisfied: soupsieve in /home/user/.local/lib/python2.7/site-packages (1.9)

[kovidgoyal]

soupsieve is installed -- probably fanficfare is using a custom beautifulsoup it should be updated to use the calibre beautifulsoup

You can test it with

calibre-debug -c "import soupsieve; print(soupsieve)"


The KDE error has nothing to do with the beta and can be ignored.