Editing content.opf with clips; Editing visibility

varlog · 04-17-2016, 06:31 PM

I've been away for a while and I admit I haven't searched the forum - so perhaps just point me

. It is not a real issue, but...
When I edit content.opf in Sigil and try to paste one of the clips in it I want to make a new line per RETURN and paste the clip in this position - so I know where I am. It is not possible - as soon as I right-click after RETURN the content.opf is modified and my clip lands at the end of the text. I can place the clip in desired position only if I right-click without prior activities. Just a small pita. Any insights?
Second small pita: when I'm editing something in a mask (for instance in Tools->Metadata Editor) the text I am overwriting is inverted but stays visible. The new text appears superimposed on the original one - visibility nightmare. When I move cursor outside of the current window the old text vanishes, only the new one stays - but when I come back it begins again. Is it Sigil or Ubuntu?

My environment: Sigil fresh from git (with my name patch

), Ubuntu 14.04 64bit, Qt 5.5.1

Turtle91 · 04-17-2016, 08:41 PM

I add the <dc:format>ePub</dc:format> tag using a clip all the time. I had to add blank spaces (CR/LF) before and after for it to insert as a new line. eg.

Code:

{CR/LF}<dc:format>ePub</dc:format>{CR/LF}

Unfortunately, you can't see the CR/LF.... but if you highlight from the end of one line to the beginning of the next (in the opf) you will get the CR/LF that Sigil uses. Then copy/paste that in the clip editor.

KevinH · 04-17-2016, 08:52 PM

It depends heavily in focus events. When focus is lost when content.opf has been edited, the opf text is auto-parsed to make sure errors have not been introduced that would break all other tools in Sigil.

So depending on your platform, desktop, and qt version, you may or may not be losing focus in the OPF tab when playing with clips causing the opf to be re-parsed. It has to work that way since Sigil does not use a commit signal or provide any way of knowing if you are done changing the opf, and the opf must be well formed for things like splitting, adding a cover, adding guide items, adding new resources, changing metadata, etc to be handled properly. We have tried to make this a bit more robust in master, but short of using a single shot timer on focus lost events that can be overwritten by later changes before it fires, I am not sure how to deal with unwanted focus lost events. It actually bothers me enough sometimes that I use Open With ... on the content.opf and then use an external editor to make my larger changes, which are then only committed when I leave the external editor. Small changes, I just edit the opf in the tab directly. An alternative idea I have been thinking about is changing just the opf edit to be a modal editing dialog window that a user must close before continuing with other Sigil functions. If we dd that we would not have to worry about focus lost events at all.

As for ghost images when overwriting text in the meta editor, I do not see that at all using the official Qt 5.4.2 builds on a Mac. Perhaps someone else can verify this on Windows. If so it may be a new Qt 5.5.1 feature/bug or something specific to Qt on Linux.

KevinH

eschwartz · 04-17-2016, 09:09 PM

I see the meta editor issues as well.

Arch Linux fully synced, Qt5 5.6.0, sigil-git latest built from HEAD, etc.

Here is a screenshot. It seems the edit field is smaller than the text field, so the text field appears as a "background".

BetterRed · 04-17-2016, 10:24 PM

Quote:

Originally Posted by KevinH

Perhaps someone else can verify this on Windows. If so it may be a new Qt 5.5.1 feature/bug or something specific to Qt on Linux.

Ok here in Sigil 0.9.4 on Win 10

BR

KevinH · 04-17-2016, 10:41 PM

So on Windows and Mac builds with Qt 5.4.2, the meta editor is fine. But on Linux with Qt 5.5.1 or Qt 5.6.0, it appears the "ghost of characters past" can be seen. I wonder if this is a Linux issue or a Qt > 5.4.2 issue. Perhaps DiapDealer can check things on his Linux build done with Qt 5.4.2 and let us know. If the issue is newer Qt version we can file a Qt bug report but no bug I have ever filed at Qt has ever been fixed. Even those with simple standalone test cases. So I don't have high hopes.

Does selection of font used have any impact on the issue? It almost appears either a border is too big or the font size metrics is being ignored when laying out the dialog fields.

KevinH

KevinH · 04-17-2016, 10:48 PM

As for the opf focus lost, I guess we could revert to simple saving of the opf in whatever state the user leaves it, but check it first each time the user tries to use any of the Sigil tools. I would just worry that user induced breakage of the opf would go undetected and could eventually cause things to get lost or funny bug reports.

I really like the idea of autofixing the opf as soon as Sigil thinks you have moved away from the open opf tab (i.e. that opf tab loses focus) as it is safer. Not sure how best to handle this is yet.

KevinH

eschwartz · 04-17-2016, 11:39 PM

Actually the meta editor thing seems to be some form of theme stupidity.

Gtk 3.20 made a lot of things look weird but on the laptop that did not get updated yet, it looks like this:

Click image for larger version

Name: meta-editor-old-gtk-theme.png
Views: 450
Size: 21.5 KB
ID: 147972

...

I am almost positive the same error appeared in calibre Editor's File Browser list at one point.

KevinH · 04-18-2016, 07:44 AM

That makes sense, calibre's file browser and Sigil's meta gui are both TreeView style widgets. Was Kovid able to work around it in some way?

KevinH

Quote:

Originally Posted by eschwartz

Actually the meta editor thing seems to be some form of theme stupidity.

Gtk 3.20 made a lot of things look weird but on the laptop that did not get updated yet, it looks like this: Attachment 147972

...

I am almost positive the same error appeared in calibre Editor's File Browser list at one point.

eschwartz · 04-18-2016, 07:45 AM

Yes, but I can't find the references to the issue so I am not sure when or how.

DiapDealer · 04-18-2016, 08:31 AM

Not sure I fully understand what people are describing with the metadata editor, I only know that I'm experiencing no visibility problems when editing/overwriting existing data on Linux Mint (Cinnamon) 17.2. Sigil git-build with Qt 5.4.2.

A theme issue does probably make the most sense, here.

Doitsu · 04-18-2016, 09:37 AM

Quote:

Originally Posted by eschwartz

I see the meta editor issues as well.

Arch Linux fully synced, Qt5 5.6.0, sigil-git latest built from HEAD, etc.

AFAIK, Qt 5.6.0 isn't officially supported.

On my Arch Linux machine I wasn't able to reproduce this issue with Qt 5.4.2
following DiapDealer's build instructions. I.e. it's most likely a Qt issue.

KevinH · 04-18-2016, 09:48 AM

So it appears to not be an issue with Qt 5.4.2 on Linux but that may in fact be dependent on the desktop and theme used.

So DiapDelaer, Doitsu, eschwartz, and varlog, what desktop/theme are you using with your builds?

I will start checking the Qt bug database for bugs related to TreeView and Linux.

Thanks,

KevinH

DiapDealer · 04-18-2016, 10:00 AM

I don't really theme around that much. I guess I'm using whatever comes stock with Mint's Cinnamon (based on GTK+ 3) Desktop. I'll have to wait until I'm back home to see if it has a specific name of some kind.

KevinH · 04-18-2016, 10:28 AM

I just looked at the Qt website for bugs relateds to TreeModel and TreeView and there are lots of them (some even causing crashes) in Qt 5.5.1 and Qt 5.6.0.

I really think Qt needs to stop pushing such fast development and instead devote some serious time to focusing on getting more stable releases. The number of unresolved bug reports is huge and huge blocks of them have been auto-closed without checking since they were in qt 4.X. So the bug reporter him or herself has to re-open them manually literally years after posting a bug that was never worked on.

I don't think it has been a full 6 months since Qt 5.4.2 was released and they have already moved to Qt 5.5, 5.5.1, 5.6.0 and seem to be leaving a long string of bugs behind them in some strange race to dump older platforms, webkit, older compilers, etc.

I think Sigil sticking to Qt 5.4.2 seems like a very good idea for the forseeable future as the number of new bugs being reported and not fixed is huge.

KevinH

04-17-2016, 06:31 PM	#1
varlog actually it is /var/log Posts: 341 Karma: 2994236 Join Date: Sep 2012 Location: usually Europa Device: prs t1	Editing content.opf with clips; Editing visibility I've been away for a while and I admit I haven't searched the forum - so perhaps just point me . It is not a real issue, but... When I edit content.opf in Sigil and try to paste one of the clips in it I want to make a new line per RETURN and paste the clip in this position - so I know where I am. It is not possible - as soon as I right-click after RETURN the content.opf is modified and my clip lands at the end of the text. I can place the clip in desired position only if I right-click without prior activities. Just a small pita. Any insights? Second small pita: when I'm editing something in a mask (for instance in Tools->Metadata Editor) the text I am overwriting is inverted but stays visible. The new text appears superimposed on the original one - visibility nightmare. When I move cursor outside of the current window the old text vanishes, only the new one stays - but when I come back it begins again. Is it Sigil or Ubuntu? My environment: Sigil fresh from git (with my name patch ), Ubuntu 14.04 64bit, Qt 5.5.1

04-17-2016, 08:41 PM	#2
Turtle91 A Hairy Wizard Posts: 3,095 Karma: 18727053 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	I add the <dc:format>ePub</dc:format> tag using a clip all the time. I had to add blank spaces (CR/LF) before and after for it to insert as a new line. eg. Code: {CR/LF}<dc:format>ePub</dc:format>{CR/LF} Unfortunately, you can't see the CR/LF.... but if you highlight from the end of one line to the beginning of the next (in the opf) you will get the CR/LF that Sigil uses. Then copy/paste that in the clip editor. Last edited by Turtle91; 04-17-2016 at 08:58 PM.

04-17-2016, 09:09 PM	#4
eschwartz Ex-Helpdesk Junkie Posts: 19,422 Karma: 85397180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	I see the meta editor issues as well. Arch Linux fully synced, Qt5 5.6.0, sigil-git latest built from HEAD, etc. Here is a screenshot. It seems the edit field is smaller than the text field, so the text field appears as a "background". Attached Thumbnails

04-17-2016, 11:39 PM	#8
eschwartz Ex-Helpdesk Junkie Posts: 19,422 Karma: 85397180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	Actually the meta editor thing seems to be some form of theme stupidity. Gtk 3.20 made a lot of things look weird but on the laptop that did not get updated yet, it looks like this: ... I am almost positive the same error appeared in calibre Editor's File Browser list at one point.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
converting epub to mobi - editing Contents.opf	aschofield	Conversion	1	06-30-2012 05:27 PM
Editing OPF	shaina	Sigil	1	12-07-2011 10:28 AM
editing OPF on sigil and adding flash file	shlomof	Sigil	5	02-23-2011 02:39 PM
Editing the OPF	crutledge	Sigil	2	06-26-2010 11:34 AM
Newbie to editing opf file	pda_junkie	Workshop	2	05-08-2010 09:58 AM

04-17-2016, 08:52 PM	#3
KevinH Sigil Developer Posts: 7,647 Karma: 5433388 Join Date: Nov 2009 Device: many	It depends heavily in focus events. When focus is lost when content.opf has been edited, the opf text is auto-parsed to make sure errors have not been introduced that would break all other tools in Sigil. So depending on your platform, desktop, and qt version, you may or may not be losing focus in the OPF tab when playing with clips causing the opf to be re-parsed. It has to work that way since Sigil does not use a commit signal or provide any way of knowing if you are done changing the opf, and the opf must be well formed for things like splitting, adding a cover, adding guide items, adding new resources, changing metadata, etc to be handled properly. We have tried to make this a bit more robust in master, but short of using a single shot timer on focus lost events that can be overwritten by later changes before it fires, I am not sure how to deal with unwanted focus lost events. It actually bothers me enough sometimes that I use Open With ... on the content.opf and then use an external editor to make my larger changes, which are then only committed when I leave the external editor. Small changes, I just edit the opf in the tab directly. An alternative idea I have been thinking about is changing just the opf edit to be a modal editing dialog window that a user must close before continuing with other Sigil functions. If we dd that we would not have to worry about focus lost events at all. As for ghost images when overwriting text in the meta editor, I do not see that at all using the official Qt 5.4.2 builds on a Mac. Perhaps someone else can verify this on Windows. If so it may be a new Qt 5.5.1 feature/bug or something specific to Qt on Linux. KevinH

04-17-2016, 10:41 PM	#6
KevinH Sigil Developer Posts: 7,647 Karma: 5433388 Join Date: Nov 2009 Device: many	So on Windows and Mac builds with Qt 5.4.2, the meta editor is fine. But on Linux with Qt 5.5.1 or Qt 5.6.0, it appears the "ghost of characters past" can be seen. I wonder if this is a Linux issue or a Qt > 5.4.2 issue. Perhaps DiapDealer can check things on his Linux build done with Qt 5.4.2 and let us know. If the issue is newer Qt version we can file a Qt bug report but no bug I have ever filed at Qt has ever been fixed. Even those with simple standalone test cases. So I don't have high hopes. Does selection of font used have any impact on the issue? It almost appears either a border is too big or the font size metrics is being ignored when laying out the dialog fields. KevinH

04-17-2016, 10:48 PM	#7
KevinH Sigil Developer Posts: 7,647 Karma: 5433388 Join Date: Nov 2009 Device: many	As for the opf focus lost, I guess we could revert to simple saving of the opf in whatever state the user leaves it, but check it first each time the user tries to use any of the Sigil tools. I would just worry that user induced breakage of the opf would go undetected and could eventually cause things to get lost or funny bug reports. I really like the idea of autofixing the opf as soon as Sigil thinks you have moved away from the open opf tab (i.e. that opf tab loses focus) as it is safer. Not sure how best to handle this is yet. KevinH

04-18-2016, 07:45 AM	#10
eschwartz Ex-Helpdesk Junkie Posts: 19,422 Karma: 85397180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	Yes, but I can't find the references to the issue so I am not sure when or how.

04-18-2016, 08:31 AM	#11
DiapDealer Grand Sorcerer Posts: 27,552 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Not sure I fully understand what people are describing with the metadata editor, I only know that I'm experiencing no visibility problems when editing/overwriting existing data on Linux Mint (Cinnamon) 17.2. Sigil git-build with Qt 5.4.2. A theme issue does probably make the most sense, here.

04-18-2016, 09:48 AM	#13
KevinH Sigil Developer Posts: 7,647 Karma: 5433388 Join Date: Nov 2009 Device: many	So it appears to not be an issue with Qt 5.4.2 on Linux but that may in fact be dependent on the desktop and theme used. So DiapDelaer, Doitsu, eschwartz, and varlog, what desktop/theme are you using with your builds? I will start checking the Qt bug database for bugs related to TreeView and Linux. Thanks, KevinH

04-18-2016, 10:00 AM	#14
DiapDealer Grand Sorcerer Posts: 27,552 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I don't really theme around that much. I guess I'm using whatever comes stock with Mint's Cinnamon (based on GTK+ 3) Desktop. I'll have to wait until I'm back home to see if it has a specific name of some kind.

04-18-2016, 10:28 AM	#15
KevinH Sigil Developer Posts: 7,647 Karma: 5433388 Join Date: Nov 2009 Device: many	I just looked at the Qt website for bugs relateds to TreeModel and TreeView and there are lots of them (some even causing crashes) in Qt 5.5.1 and Qt 5.6.0. I really think Qt needs to stop pushing such fast development and instead devote some serious time to focusing on getting more stable releases. The number of unresolved bug reports is huge and huge blocks of them have been auto-closed without checking since they were in qt 4.X. So the bug reporter him or herself has to re-open them manually literally years after posting a bug that was never worked on. I don't think it has been a full 6 months since Qt 5.4.2 was released and they have already moved to Qt 5.5, 5.5.1, 5.6.0 and seem to be leaving a long string of bugs behind them in some strange race to dump older platforms, webkit, older compilers, etc. I think Sigil sticking to Qt 5.4.2 seems like a very good idea for the forseeable future as the number of new bugs being reported and not fixed is huge. KevinH

Advert

Advert