View Single Post
Old 01-07-2016, 07:11 AM   #163
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,893
Karma: 6120478
Join Date: Nov 2009
Device: many
Hi rubeus,
I have never ever seen it on my Mac. Therefore, I did not know a user could ever see the result.xml file on screen (even briefly). You should always clearly see your output you wrote to stdout in the plugin and nothing else.

In other words, your "Scanning Text/coverpage.xhtml..." line with a status of Success should stay their until you close the dialog.

If your plugin returned an error or threw an uncaught exception, that screen would stay to help the plugin developer and Sigil developers to know what is wrong.

Right now, the Sigil console window shows everything written to stdout and stderror being sent back from the python process running the plugin. We do this in case of a hang or infinite loop.

Once it completes, the console window is reset to just stdout. In the brief instant before being reset you are seeing the result.xml file that Sigil uses to safely merge your changes back into the official directory holding the ebook being worked on.

I will modify the code to strip out any result.xml info but you still might see the console screen flicker once when it resets to show only stdout on success. That was how it was designed to work anyway, I had no idea the result.xml could ever be seen.

KevinH



Quote:
Originally Posted by rubeus View Post
Hi,

i was capturing it cause it was unreadable. And what would you assume if you are testing a plugin producing output disappearing so fast it cant be read. Isnt it so far away to assume an erro in your plugin you wanna tear down? I had a look at it cause it was presented to me. And would an enduser thinks starting the plugin being aware of the same? Is it so hard to think about he might believe that the plugin went wrong and destroyed the epub. I'm tired reading those assumptions. They can only come from a developer not be able to change gus point of view. I think i need to take some break when asking here and getting such a response: Hey dude, this message isn't for you! Don't look at it!

By the way, a quadcore with 2.5 Ghz having nothing to do isnt really slow.....

@Kevin: When updateing a file with bk.writefile(id, soup.serialize_xhtml()) the screen with my messages disappears, then for a tenth of a second or may be two the xmls is presented. If you do this in loop writing back a lot of files the plugin launcher window starts to flicker. In my first assumption i thought this came from sigil_bs4 or PIL using the libs in a wrong way so i did a screen recording to find out what these messages are about.
KevinH is offline   Reply With Quote