[FileType Plugin] GetFileName

[Terisa de morgan]

@BetterRed, I think it's already corrected but your configuration is not right. If you want to store the file name with path, the column which should be filled is "File name", not "File Path"

[BetterRed]

Originally Posted by Terisa de morgan

@BetterRed, I think it's already corrected but your configuration is not right. If you want to store the file name with path, the column whic h should be filled is "File name", not "File Path"

@Terisa de Morgan - I am totally & utterly confused, you tell me here I have the PI wrongly configured, yet you issue a new release to correct the problem I reported.

A 'file path' by definition includes its location, if the column specifier called File Path now means the File Location you should give it a new label.

I am 99.99% certain that the way I had it (see attachment 2 in post #71) worked up until Dec 24. I have hundreds of books added before that date that are OK. I am 99.99% certain I didn't change the PI configuration on that date, but I did install version 0.0.7 on that date.

The way I had it configured made sense semantically. IMO asking for 'file path' and then putting the column name in a variable called 'file name' when there's another variable called 'file path' is somewhat bizarre/weird, perverse even

If the current purpose of the File Path column specifier is to specify the File Location I suggest the configuration dialogue be changed accordingly - see attachment.

For aesthetic reasons I would also swap the Without Path and With Path radio buttons. Or, better yet replace them with a "Put full file path in File Name column: " check box. IIRC the best practice UI convention is to use check boxes for either/or choices, and radio buttons when there are between three and seven options to choose from. I appreciate why you might not want to do this.

BR

[Terisa de morgan]

Originally Posted by BetterRed

A 'file path' by definition includes its location, if the column specifier called File Path now means the File Location you should give it a new label.

Not for me

Originally Posted by BetterRed

The way I had it configured made sense semantically. IMO asking for 'file path' and then putting the column name in a variable called 'file name' when there's another variable called 'file path' is somewhat bizarre/weird, perverse even

Not really. I'm requesting if the file name includes path and the tip in file path says: It stores the file path. If not included, the file name is not split.

Originally Posted by BetterRed

If the current purpose of the File Path column specifier is to specify the File Location I suggest the configuration dialogue be changed accordingly - see attachment.

I disagree in this, sorry. BTW, on my commute this morning I thought a bit and I expected this comment

Originally Posted by BetterRed

For aesthetic reasons I would also swap the Without Path and With Path radio buttons. Or, better yet replace them with a "Put full file path in File Name column: " check box. IIRC the best practice UI convention is to use check boxes for either/or choices, and radio buttons when there are between three and seven options to choose from. I appreciate why you might not want to do this.

Well, I like your suggestion for this but.. it's not right because, if you fulfill path and name column, the name column doesn't include the file path

[BetterRed]

Never mind. Fortunately I hadn't gotten around to abandoning my old way of capturing the document source. Capturing the path was a belt to its braces.

BR

[Terisa de morgan]

As I say, I can change the check but the name or the other concept... I don't agree. And I'm afraid that it was a bug the reason it was working before.

[BetterRed]

Terisa de Morgan, What you regarded as a bug was for me an established, rational behaviour that did what I wanted.

Prior to the bug fix, the configuration shown below was allowed, and it produced a verifiable result - i.e. the full path was put into the column specified in File Path



But since the bug fix, that configuration is still allowed, but it produces no result - i.e. nothing is put into the column specified in File Path.

In my book that's a bug. If the configuration is invalid (because there's no column specified for File Name) then the PI should issue a message when a Book is added and abort the add. If it's not invalid then it should produce a verifiable result - such as putting the file location (path without filename & extension) into the specified column. Anything, except do nothing.

BR

[Terisa de morgan]

I totally agree, it's a configuration bug I'll try to correct in a new version (extension and path will be disabled till name is fulfilled).

[BetterRed]

Originally Posted by Terisa de morgan

I totally agree, it's a configuration bug I'll try to correct in a new version (extension and path will be disabled till name is fulfilled).

I hereby promise to test it when its released

BR

[Terisa de morgan]

Added 0.0.10 version => It shows not allowed configurations. It doesn't remove the previously configured columns, that doon't work.

[Giuseppe Chillem]

Hi Terisa, the plugin is not working for me.

Directory and Files:



D:\________TEMP\L\ti\Antoninu Rubattu - Dizionario e Grammatica Sardo\
Antoninu Rubattu - Dizionario Universale Della Lingua Di Sardegna A - L.pdf
Antoninu Rubattu - Dizionario Universale Della Lingua Di Sardegna M - Z.pdf
Grammatica Sarda Campidanese.pdf
LEGGI INFO IMPORTANTE.txt


The plugin imports only the third one:

Grammatica Sarda Campidanese

Privately I am sending you a link to zip file with all the books.

[Terisa de morgan]

Hi Giuseppe,

I'm afraid I can do nothing as the problem is in the Grammatica Sarda. If I add the other two books together, I always get the name. If I add the three books, it's a bit of hit and miss. Sometimes all of them get the name, sometimes only two, sometimes only one. But the problem is that the plugin itself is not called, as there are some calibre logs of problems with the Grammatica Sarda that I don't understand but that avoid the plugin.

If you add the two dictionaries together, you'll get the proper data.

Sorry, I can do nothing more, as I don't know the reason of the calibre errors.

Spoiler:

Traceback (most recent call last):
File "site-packages\calibre\ebooks\metadata\xmp.py", line 346, in consolidate_metadata
File "site-packages\calibre\ebooks\metadata\xmp.py", line 239, in metadata_from_xmp_packet
File "site-packages\calibre\ebooks\metadata\xmp.py", line 76, in parse_xmp_packet
File "lxml.etree.pyx", line 3032, in lxml.etree.fromstring (src\lxml\lxml.etree.c:68121)
File "parser.pxi", line 1786, in lxml.etree._parseMemoryDocument (src\lxml\lxml.etree.c:102470)
File "parser.pxi", line 1674, in lxml.etree._parseDoc (src\lxml\lxml.etree.c:101299)
File "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc (src\lxml\lxml.etree.c:96481)
File "parser.pxi", line 582, in lxml.etree._ParserContext._handleParseResultDoc (src\lxml\lxml.etree.c:91290)
File "parser.pxi", line 683, in lxml.etree._handleParseResult (src\lxml\lxml.etree.c:92476)
File "parser.pxi", line 622, in lxml.etree._raiseParseError (src\lxml\lxml.etree.c:91772)
XMLSyntaxError: Start tag expected, '<' not found, line 1, column 1

[Giuseppe Chillem]

Hope Kovid will help

[kovidgoyal]

That's an error reading metadata from the PDF file, I dont see why it should affect a file type plugin. See the read_metadata() function in metadata worker -- the import plugins are run before metadata is read. The only case of not running an import plugin I know of is if the file itself is not added -- for exmaple if it is a duplicate and calibre is set to ignore duplicates.

[Terisa de morgan]

I don't know the reason either but the plugin is not being called. I'll try to test a bit more or running from source, for checking it.

[Terisa de morgan]

I have to run calibre from source for finding the reason the plugin not being called (the postadd method is not running), I'll tell you if I can find it.