0.7.700 Alpha Ready For Testing

[KevinH]

Hi DiapDealer,

Hmm ... that may explain why you can unpack and work with joint mobis but I simply could not see how that could even work based on the code!

As your guimain class inherits from Frame, do you think maybe destroy() or quit() needs to be called on itself? If so that should tell your mainloop to exit as the only frame has quit. Then I guess you could follow-up by adding a root.destroy() in run after the mainloop?

So maybe something like the following might work (just a guess here)

in quitApp(), maybe it should end like the following:

def quitApp(self):
self.destroy()
# or maybe the above should simply be self.quit()

But then in run you do the following:

def run(bk):

root = Tk()
root.title('')
root.resizable(True, True)
guiMain(root, bk).pack(fill=Tkconstants.BOTH, expand=False)
root.mainloop()
root.destroy()
return 0


Again, this is just a guess ... I will play around with it on my Mac tonight when I get home from work and see if the same issue happens.

Take care,

KevinH

Originally Posted by DiapDealer

Hey Kevin,

I'm finding some weird behavior with the plugin that I can't really explain (at least on Linux). Suffice to say that I think the full Tk mainloop approach may be introducing some unwanted issues. Once I select a file to process, I simply cannot programmatically stop the plugin (close/destroy the root window) based on certain criteria. It tries to unpack anything I feed it--even though I specifically tell it to jump to the quitApp function if a KF8 book isn't detected (and it does go to the quitApp function--it just also continues to try to unpack). Simply put: the only thing that seems to close the plugin's gui programmatically (once it gets to the doit function) is complete success. Puzzling.

[DiapDealer]

Originally Posted by KevinH

Hi DiapDealer,

Hmm ... that may explain why you can unpack and work with joint mobis but I simply could not see how that could even work based on the code!

Yep. It was definitely working by accident! I see now how it should have been excluding joint mobis. I can fix that pretty easily once this particular weirdness is solved.

As your guimain class inherits from Frame, do you think maybe destroy() or quit() needs to be called on itself? If so that should tell your mainloop to exit as the only frame has quit. Then I guess you could follow-up by adding a root.destroy() in run after the mainloop?

So maybe something like the following might work (just a guess here)

in quitApp(), maybe it should end like the following:

def quitApp(self):
self.destroy()
# or maybe the above should simply be self.quit()

But then in run you do the following:

def run(bk):

root = Tk()
root.title('')
root.resizable(True, True)
guiMain(root, bk).pack(fill=Tkconstants.BOTH, expand=False)
root.mainloop()
root.destroy()
return 0


Again, this is just a guess ... I will play around with it on my Mac tonight when I get home from work and see if the same issue happens.

Take care,

KevinH

That's basically what I'm doing now. Except I call self.parent.destroy() in the quitApp method instead of root.destroy() in the main run() method. I think perhaps that somehow I'm preventing control from being handed back to the wrapper/launcher (except in the case of the bk.add() call). I still don't know why it proceeds with the unpack, though. It almost seems as though it's unpacking in parallel with the quitApp call.

[DiapDealer]

I think I need to go back to my original method of just using tkinter to get a file path -- rather than trying to do all the plugin's logic, processing, and error raising inside the mainloop.

[Doitsu]

FYI, for good measure I've also tested DiapDealer's KindleImport plug-in on a 64-bit Linux machine (with Python 2.7.3) and didn't get any pathof warnings.

I.e., this might be a 64-bit Windows Sigil build issue, a Windows 8 issue or a 64-bit ActivePython 2.7.8.1 issue.

@DiapDealer: Since the plug-in definitely works, maybe you could simply readme this behavior and move on to more interesting things instead of debugging Windows-only bugs. :-)

@Sigil 0.7.7 Windows beta testers: Can you please test DiapDealer's KindleInput plugin on your machine and report back whether you're also getting pathof warnings at the end? (You can use this .azw3 file as input file.)

[DiapDealer]

Originally Posted by Doitsu

@DiapDealer:[/B] Since the plug-in definitely works, maybe you could simply readme this behavior and move on to more interesting things instead of debugging Windows-only bugs. :-)

But what could be more fun that tracking down pesky, elusive bugs?

[najgori]

Originally Posted by Doitsu

@Sigil 0.7.7 Windows beta testers: Can you please test DiapDealer's KindleInput plugin on your machine and report back whether you're also getting pathof warnings at the end? (You can use this .azw3 file as input file.)

yes. (on win7 64bit, python 64bit)

[SHunter101]

Originally Posted by Doitsu

I.e., this might be a 64-bit Windows Sigil build issue, a Windows 8 issue or a 64-bit ActivePython 2.7.8.1 issue.

@DiapDealer: Since the plug-in definitely works, maybe you could simply readme this behavior and move on to more interesting things instead of debugging Windows-only bugs. :-)

@Sigil 0.7.7 Windows beta testers: Can you please test DiapDealer's KindleInput plugin on your machine and report back whether you're also getting pathof warnings at the end? (You can use this .azw3 file as input file.)

Hello:

Really happy Sigil is being worked on again!!

Tested on Win8.1 64bit using python 2.7.2 32bit (active python 2.7.2.5). I have not updated my python in a while. I can test python 64bit version if needed. Let me know. Also using Sigil 7.7 64bit.

Status: success

Entering KindleUnpack input plugin's run() routine
Path to Kindlebook C:/Downloads/eBook Stuff/Finati, Giovanni - The Life and Adventures of Giovanni Finati.azw3
Palm DB type: BOOKMOBI, 105 sections.
Unpacking a KF8 book...
Processing K8 section of book...
Mobi Version: 8
Codec: utf-8
Title: The Life and Adventures of Giovanni Finati
Palmdoc compression
Unpacking images, resources, fonts, etc
Extracting image: cover00097.gif from section 97
Extracting image: image00099.jpeg from section 99
Unpacking raw markup language
Processing ncx / toc
Write K8 ncx
Building an epub-like structure
Building proper xhtml for each file
Building a cover page.
Building an opf for mobi8 using epub version: 2
Building Navigation Document.
Creating an epub-like file
Path to new epub c:\users\kirred\appdata\local\temp\tmpbycat_\mobi8 \Finati, Giovanni - The Life and Adventures of Giovanni Finati.epub
Warning: pathof expects utf-8 encoded byestring: C:\Users\KirRed\AppData\Local\Temp\Sigil\scratchpa d\3ba799db-a5ca-4d7b-96bd-4d4c218aa2db\new.epub
Warning: pathof expects utf-8 encoded byestring: C:\Users\KirRed\AppData\Local\Temp\Sigil\scratchpa d\3ba799db-a5ca-4d7b-96bd-4d4c218aa2db\new.epub
Warning: pathof expects utf-8 encoded byestring: C:\Users\KirRed\AppData\Local\Temp\Sigil\scratchpa d\3ba799db-a5ca-4d7b-96bd-4d4c218aa2db
Warning: pathof expects utf-8 encoded byestring: C:\Users\KirRed\AppData\Local\Temp\Sigil\scratchpa d\3ba799db-a5ca-4d7b-96bd-4d4c218aa2db\new.epub

Best,
Shunter

[Divingduck]

Hi KevinH and user_none,
fine to see you back. Is it possible to have an update for the translation file at Transifex? As there are some additional strings in the GUI, I like to update the translation too.
Best regards,
DD

[Divingduck]

@Doitsu,
same to me (WinVista64bit):

Spoiler:

Status: success

Entering KindleUnpack input plugin's run() routine
Path to Kindlebook C:/Users/Armin/Documents/Sigil/Alpha-Test/Finati, Giovanni - The Life and Adventures of Giovanni Finati.azw3
Palm DB type: BOOKMOBI, 105 sections.
Unpacking a KF8 book...
Processing K8 section of book...
Mobi Version: 8
Codec: utf-8
Title: The Life and Adventures of Giovanni Finati
Palmdoc compression
Unpacking images, resources, fonts, etc
Extracting image: cover00097.gif from section 97
Extracting image: image00099.jpeg from section 99
Unpacking raw markup language
Processing ncx / toc
Write K8 ncx
Building an epub-like structure
Building proper xhtml for each file
Building a cover page.
Building an opf for mobi8 using epub version:  2
Building Navigation Document.
Creating an epub-like file
Path to new epub c:\users\armin\appdata\local\temp\tmpbgn5ik\mobi8\Finati, Giovanni - The Life and Adventures of Giovanni Finati.epub
Warning: pathof expects utf-8 encoded byestring:  C:\Users\Armin\AppData\Local\Temp\Sigil\scratchpad\b139142b-c12d-4723-bdd2-14f8a5dc107f\new.epub
Warning: pathof expects utf-8 encoded byestring:  C:\Users\Armin\AppData\Local\Temp\Sigil\scratchpad\b139142b-c12d-4723-bdd2-14f8a5dc107f\new.epub
Warning: pathof expects utf-8 encoded byestring:  C:\Users\Armin\AppData\Local\Temp\Sigil\scratchpad\b139142b-c12d-4723-bdd2-14f8a5dc107f
Warning: pathof expects utf-8 encoded byestring:  C:\Users\Armin\AppData\Local\Temp\Sigil\scratchpad\b139142b-c12d-4723-bdd2-14f8a5dc107f\new.epub

Originally Posted by Doitsu

@Sigil 0.7.7 Windows beta testers: Can you please test DiapDealer's KindleInput plugin on your machine and report back whether you're also getting pathof warnings at the end? (You can use this .azw3 file as input file.)

[KevinH]

Hi DivingDuck

Originally Posted by Divingduck

Hi KevinH and user_none,
fine to see you back. Is it possible to have an update for the translation file at Transifex? As there are some additional strings in the GUI, I like to update the translation too.
Best regards,
DD

Unfortunately, I have not been careful wrapping all needed gui Qt strings in tr() in the new Plugin code so much of the needed translations will not have been made or even marked to be made. I will work with user_none to get that fixed for the next release (beta) and hopefully we can then collect all the strings needing translation and get that process restarted.

Thanks,

KevinH

[varlog]

I was away from internet for last month and a lot happened in the meantime... but I will certainly try to take part.
last commit needs to be corrected:
Plugin.cpp
-#elif deifned(_WIN32)
+#elif defined(_WIN32)
to be compiled - but you know it already, I think.
I miss context menu. Perhaps not important really.
I miss an opportunity to register librarys: plugins should be able to use other plugins/third party code with no changes.

[KevinH]

Hi varlog,

Thanks for the typo fix. Added it to my github tree for user-none to pull.

I miss context menu. Perhaps not important really.

It was not high on my agenda. It might be something we add after the official release.

I miss an opportunity to register librarys: plugins should be able to use other plugins/third party code with no changes.

If you have non-standard library python code you want to add for your plugin, you can add it to your main plugin directory and use ctypes to pull in any local dll/dylib/so.

Python Plugins will not be able to use other plugins directly. Simply incorporate their code into your project if you need it as you would any other python code.

Take care,

KevinH

[varlog]

On my Ubuntu (14.04) compiling 0.7.700 (git latest) with Qt Creator (3.1.2 opensource) I don't get share/sigil/plugin_launchers folder in my build folder, I have to copy it manually. Is it design, do I miss something?
-DCMAKE_INSTALL_PREFIX is set to my build folder

Why lua is no more?

On the side:

Originally Posted by KevinH

Python Plugins will not be able to use other plugins directly. Simply incorporate their code into your project if you need it as you would any other python code.

Maintenance problems... duplicating code... .

[DiapDealer]

Originally Posted by varlog

-DCMAKE_INSTALL_PREFIX is set to my build folder.

Do you mean that you've set your install prefix to the same directory as the build directory (where you first issue the cmake command)?

I've absolutely no experience with using Qt Creator as part of the build process. Just cmake, make, make install.

[KevinH]

Hi,

Originally Posted by varlog

On my Ubuntu (14.04) compiling 0.7.700 (git latest) with Qt Creator (3.1.2 opensource) I don't get share/sigil/plugin_launchers folder in my build folder, I have to copy it manually. Is it design, do I miss something?
-DCMAKE_INSTALL_PREFIX is set to my build folder

Not sure, user-none has been changing some of the install locations to remove the lua code, something may have broken? I will look into it.

Why lua is no more?

Lack of decent support for gui widgets, lack of decent support for xml parsers and processors, no real support for full unicode. All solvable given time but doing so would delay the actual release for not much reward given Lua has too small a user base. Instead we have focused on making the launcher code run on both python2.7, and python3.4 so we can now support both python and python 3 plugins. We will probably skip the beta and make a full release soon so that we can turn our attention to epub 3 support.

Maintenance problems... duplicating code... .

Then simply add those python libs to your python interpreter sys.path search so they can be found by any python program. That way no duplicating of code. That is true of any python program.