Sigil 0.2.1
 

OK, I just pushed the (not so) small bugfix release before my several week coding pause. Blog post with details here.

thanks valloric ! downloading immediately. :) i hope you'll be sleeping at least a little bit during your coming code-free weeks. ;)

Wow!

Thanks for the hard work. :thanks:

I am good at breaking Sigil ;) ( .2.1 on XP SP3)

Single tab edits in code view still reverting when switching to book view. (does selecting text R to L, for edits, affect things differently? Seems if I selected text L to R, no problems.)

Consecutive S+R's (down) ALL HTML hangs on second (from start point) pass with tabs already open (caret is at /near bottom of pages from previous S&R). (Process explorer shows no CPU cycles being used)

Unknown hangs on Save?

Please try to make it repeatable, then create a new issue on the tracker.

I have no idea what you just said here.

Are you saying you've seen some hangs on save with 0.2.1?

If I select text moving Right to Left, and apply a "action" (Bold, Center...) it tends to revert.
If I select Left to Right and apply the action. It "Takes"

Yes, Random. May be triggered by initiating a second save because I did not believe the first click was recognized . (an immediate "Saving" message would be nice. I know the "File Saved appears for a very Brief time.

Is it possible to add an "un-saved" mark (*) to any tab label with un-saved changes?

It works for me selecting text both ways. Try to make a repeatable, detailed, step-by-step procedure in a new issue on the tracker.

I just rapidly saved a large epub file in quick succession multiple times, and it works just fine. No hang.

Again, I can't fix it if I can't reproduce it. Try to make a repeatable procedure. :)

Sigh!
There has to be something weird with my XP rig,
I seem to get this issue a lot. :rolleyes:

Code view. I see my change(s) , Switch views and they are gone.

I have had "tidy" put things back if I did not get a tag exactly correct.
In this type of case, the edit did not break a tag pair /attribute

This is not a problem that has been reported before. There was a problem with F&R dialog replacements not sticking, but that should be fixed now.

Did you have this problem in 0.2.0 or did it just appear in 0.2.1?

It appeared in 2.1, not the same as it was before, where clicking in a document locked in the S&R.
This was a simple edit (remove words).

It was so bad this morning (3 or 4 times it did it to me), I rolled back to 2.0 .

(First, I tried: Removed Sigil via the windows control panel.
The program files dir vanished as expected.
I then re-installed Sigil 2.1 (prior was done as upgrade).

No Joy.

Removed and installed 2.0 :)

I will play with the Linux 2.1 later and see if it happens there.

When it happened, were you working in Split View and then clicking between the two panes, or just switching directly between full Book View and full Code View?

The more information you can provide on what you were doing when it happened, the better. Did you use the shortcut to switch, or did you press the button in the menu or the toolbar? As much detail as possible, please.

Not Split View

BTW I just tried a file I had trouble with on Windows on Ubuntu. No problem doing a task I tried many times to do on Windows version.:chinscratch:

Got to be my system :( is bad Sigil is running slower than it was, when I first switched to 2. Beta

I was just about to say that it must be your system, for several reasons:

1. Nothing changed in the way CV -> BV transition is preformed (or the other way around) between 0.2.0 and 0.2.1.
2. I've been staring at the relevant pieces of code for the past hour, and there's just no way that you could make a change in CV, switch to BV and not have the changes applied there.

There are three content caches for HTML tabs, for performance reasons. There's the QWebPage which holds the rendered state of the HTML and is the main cache for Book View. When you type in BV, this is what you're changing. Then there's the QTextDocument which holds the syntax highlighted text for the Code View, and is its main cache. Again, you're editing this in CV. And then there's QDomDocument, which is the central, "neutral", DOM cache which represents the actual state of the HTML resource.

When you edit in a View and then leave the tab, Sigil catches the loss of focus on the tab and saves the changes from one of the secondary caches (QWebPage, QTextDocument) to the primary one (QDomDocument). When the tab regains focus or the user switches to it without giving it focus, the secondary cache of the current View is updated.

Now, when you switch between the Views, the primary cache is circumvented, and the changes are applied directly between the two secondaries (again, performance).

The absolutely only way that you could edit in CV, switch to BV and not have the changes transfer... well several things would need to happen:

1. You'd have to find some unimaginable way of circumventing the secondary cache sync algos. Normally I'd say that was impossible: you can't click a button or the shortcut for switching views without invoking them. No way, period.
2. Then you'd have to enter BV without being in CV before it... again, how exactly if you just pushed a button do it? But let's say you did, you'd now be entering BV as if the tab was just opened or the focus was in, say, the Book Browser and now the BV syncs from the primary cache.
3. And then, the primary cache would need to out of date for the BV to sync to the "old" content. Again, impossible. Even if step 2 worked, and you left CV and entered BV by some freaky way, CV would still update the primary cache on losing focus.

Bottom line? The only way all of this could maybe (and that's a ridiculous maybe) happen is if your OS isn't sending focus events the way it should... or QtWebKit exploded... or whatever.

If you're seeing this behavior on one machine and not the other, then the first machine has more serious problems than Sigil.

Thanks for looking.
Since no one else is griping, it must be my XP system

Now I got to figure what is wrong (reloading XP is a PITA) with this beast. as it pretty well works for most stuff.

No No It's Not Just Ducky! ME TOO!
 

Hold it, it's not just Ducky or theDucks.

This has happened to me repeatedly since yesterday when I downloaded 0.21, in fact last night when I was trying to get my &^%$#@ to validate on epub 1.05, I had to go back and make a crapload of changes, and they just don't...for lack of a better word, STICK. I have this problem repeatedly on S&R- if I make a change and close the s&r box, and, heavens forbid, change the view to WYSIWYG, the changes in cdodeview disappear and are not saved.

It is particularly egregious on s&r, although I have had it happen with manual changes, also. I made some s&r changes last night, saved it, ran the validator, and, kablammo!--same errors. Went back, looked, and the changes had quite simply "undone." It's like using CTRL-Z on a global basis.

@Ducky, you ain't alone, and @Valloric, it isn't something he's doing, at least, not uniquely.

I am running XP 32-bit.

Hitch