0.6 Beta take 3 (0.5.906)

[paulhypno]

Working in Book View I can't make the 'Undo' command work. Have I missed something?

[kiwidude]

Originally Posted by paulhypno

Working in Book View I can't make the 'Undo' command work. Have I missed something?

No, it doesn't work in previous versions either (for certain actions). It is a limitation of using Qt Webkit, because some actions like applying a heading style have to be done in javascript behind the scenes and there is no "undo" for operations like that. You can paste/type code and undo that, but other things you cannot.

There are also some actions in Code View which you can't undo either, where it results in the entire html being replaced (like Replace All or splitting). And of course once you switch views you also lose your undo history from Book View.

It is an immensely complex problem to try to solve, which we haven't attempted in the slightest to sort out in lieu of other priorities. We haven't made the behaviour worse than it was previously, put it that way

[mrmikel]

If/when auto save is developed in future, it could just save changes in the documents, instead of the whole documents. It would not allow you to pull documents out of Sigil, but the resulting files could be a lot smaller.

[paulhypno]

Thank you kiwidude. Whatever, it's a price worth paying for the excellent development of this indispensable program

[ElMiko]

Originally Posted by kiwidude

Ummm, the shortcut for Count All is Alt+C (Ctrl+A would conflict with built in behaviour of controls to select all the content).

There is an inconsistency in the 905/906 beta when it comes to button/menus/shortcuts enabled around F&R when you are in Book View/Preview View. In that the options on the Search menu (and hence the keyboard shortcuts) are disabled, but you can click on the buttons (which does the "right" thing of switching to Code View so it can do the action),. I have already fixed this for the next release.

Sorry, I meant "Alt+A", but it looks like you've got this one under control! In that case, how's about this one: window resizing. Sigil seems to forget size and position of its windowed mode from one session to the next if it was maximized (ie not windowed) when you last closed it, instead centering it and resizing it to more-or-less a perfect square. This is totally granular and nitpicky, but given the frequency with which i open & close Sigil, I thought I'd throw it out there.

[kiwidude]

Originally Posted by ElMiko

Sorry, I meant "Alt+A", but it looks like you've got this one under control! In that case, how's about this one: window resizing. Sigil seems to forget size and position of its windowed mode from one session to the next if it was maximized (ie not windowed) when you last closed it, instead centering it and resizing it to more-or-less a perfect square. This is totally granular and nitpicky, but given the frequency with which i open & close Sigil, I thought I'd throw it out there.

Ahh, another "always done that" behaviour

That is how the Qt framework works when it comes to saving positions. If you have multiple screens and maximise the window on a non primary screen, you will also notice it reopens maximised on your primary screen. Maximising Sigil is not something I do on my screens so it hasn't bugged me before now

I think in theory it would be possible to work around it. I'll put it on the rainy day wish list.

[ElMiko]

I'm fairly certain that previous versions of sigil remember the location and dimensions of a windowed screen... but maybe i'm losing my mind. For me, my workflow is mostly in a windowed mode so I can have Sigil open on one side of the screen and the reference pdf on the other. But when it comes time to run through spellcheck, I maximized the window (just to cut down, however marginally, on Page Dn presses). Unless I remember to re-window it after i finished spellchecking, the next time I go to open Sigil, it will be in maximized mode (which is only logical, since that's how it was closed), but when I go to window it, it will have forgotten dimensions and location of the last windowed mode (ie, on the right hand half the screen, fully extended top-to-bottom).

Remembering to window it after spellchecking (but before closing) is not by any stretch a gigantic inconvenience. And, really, neither is re-positioning the windowed view in the event i forget to un-maximize. Just thought I'd put it out there... heaven knows I've been trying to come up with a substantial bug/fix request, but you guys have apparently done too good a job. Curses!

[Man Eating Duck]

Originally Posted by ElMiko

Remembering to window it after spellchecking (but before closing) is not by any stretch a gigantic inconvenience. And, really, neither is re-positioning the windowed view in the event i forget to un-maximize.

Just a general tip (which you might be aware of): if you're on Win7 try Windows + Arrow keys on a Window which is in focus. It will maximise/minimize your window, and put it on either side of your screen. Something similar can be accomlished on KDE and Gnome with custom shortcuts.

It might not remember your position, but it makes it a matter of a keypress to reposition

[kiwidude]

@ElMiko - sorry when I said "always done that" I meant always done that with Qt 4.8 which all the 0.5.9 betas have been based on. It believe this is the issue which theducks reported six months or so ago with the initial beta (though I never had the steps to reproduce it which I do now, thanks).

[meme]

Originally Posted by ElMiko

Would it be possible to have an option in the TOC builder that allows you to keep all the heading levels, but UN-nests them?

As kiwidude mentioned, this is the Manually Edit TOC feature which is unlikely to be in 0.6.0 The new version of Generate TOC allows you to change the heading level of the headings inside of Generate TOC - but it also changes the heading tags in the document directly. So if you move h2 to h1 in the TOC, the heading in your file will automatically be udpated from h2 to h1 tags. You can of course edit the title this way as well. Just remember to check your formatting afterwards

Originally Posted by mrmikel

If/when auto save is developed in future, it could just save changes in the documents, instead of the whole documents. It would not allow you to pull documents out of Sigil, but the resulting files could be a lot smaller.

I believe that would be the plan if it can be implemented.

[meme]

Just a heads up that the next version of the beta will change the way Saved Searches and Clips are saved - so you will need to manually copy your entries to a new file. This is necessary to remove a bit of clutter from the main sigil.ini config file and to make it easier to copy/move just clips or searches around. But mainly it started when we wanted to make sure that if you ran separate instances of Sigil that the Saved Searches and Clips where kept in sync: if you Save your searches/clips in one Sigil, the others will immediately reload the config files so all copies have the same entries and you don't accidentally overwrite (as long as you Save them after changing!).

As you may have noticed, many of the shortcuts have changed (the less used ones), and of course you had to re-assign them anyway with the beta. There are a couple more shortcut changes (to align left/right), so it would be a good idea to clear your shortcuts.

In fact, for the next beta - and we'll post a reminder when its released you should:

• Copy the sigil.ini file to sigil-oldbeta.ini just in case
• Edit sigil.ini and copy out the clip entries
• Paste that data into a new file in the same directory called sigil_clips.ini
• Edit sigil.ini and copy out the search entries
• Paste that data into a new file in the same directory called sigil_searches.ini

Then:

• After starting the new Sigil you should use Edit->Preferences->Keyboard Shortcuts->Reset All
• OR just rename sigil.ini sigil-old.ini to get a clean start (dictionaries are not touched).

Don't worry - all this will be posted again for the beta, but just wanted to let you know it was coming.

[theducks]

Originally Posted by ElMiko

I'm fairly certain that previous versions of sigil remember the location and dimensions of a windowed screen... but maybe i'm losing my mind. For me, my workflow is mostly in a windowed mode so I can have Sigil open on one side of the screen and the reference pdf on the other. But when it comes time to run through spellcheck, I maximized the window (just to cut down, however marginally, on Page Dn presses). Unless I remember to re-window it after i finished spellchecking, the next time I go to open Sigil, it will be in maximized mode (which is only logical, since that's how it was closed), but when I go to window it, it will have forgotten dimensions and location of the last windowed mode (ie, on the right hand half the screen, fully extended top-to-bottom).

Remembering to window it after spellchecking (but before closing) is not by any stretch a gigantic inconvenience. And, really, neither is re-positioning the windowed view in the event i forget to un-maximize. Just thought I'd put it out there... heaven knows I've been trying to come up with a substantial bug/fix request, but you guys have apparently done too good a job. Curses!

I reported that a while back (I have a 3 Head system). And yes, previous (V5) versions remembered. What changed was the version of QT (user_none built me a test build with the old QT and it behaved the old way. There are desirable features that Sigil wants in the new QT so we just have to put up with the Window issue until QT gets fixed.

I see Kiwidude beat me again

[Araucaria]

Originally Posted by Perkin

In BookView, try copying the required search text from one instance into clipboard and paste that into search box then do the replace (may be font used displaying as what you think is a single quote, whereas it should be single right/left quote).

Also as 'ducks says, try working in CodeView, they (both single quotes) may look together in BookView but may contain something in between them in CV, such as an invisible/empty link or anchor.
Then things will get slightly harder to sort it out.

Let us know if anything works, or if there is anything in CodeView which will make it more difficult to do a replace, As it just may need a copied sample of that CV text to fine tune a regex to do a global replace.

I think it was just a font problem, and that Sigil does work the way it's supposed to - my apologies for raising a non-issue.

I had started by cutting and pasting from the text in code view into the search/replace boxes. What I hadn't appreciated was that if you cut and paste two separate single quote marks from the code into the search box, when they appear in the search box, they look like a double quote instead. Seeing what appeared to be the wrong target in the search box made me replace it with single quotes with a space between: that made the box below and the text above look the same. Naturally it found nothing. Obviously (and only now do see I hadn't tried doing the obvious thing) I should have trusted the cut and paste method, which does smarten up the OCR results the way I wanted.

Thanks for your kind and helpful answers.

I'm afraid I don't yet understand how to do Regex operations so I don't do them. No doubt it would save me a lot of time, and I will get around to it soon.

[kiwidude]

@Arucaria - another way to prevent copy/paste errors is to simply just select the text in Code View / Book View / Preview View and hit Ctrl+F (for "Find"). That automatically puts the selection into the Find field for you, without you having to do anything else. Then just hit tab to move into the Replace field, type your replacement and you are good to go...

[kiwidude]

Originally Posted by theducks

I reported that a while back (I have a 3 Head system). And yes, previous (V5) versions remembered. What changed was the version of QT (user_none built me a test build with the old QT and it behaved the old way. There are desirable features that Sigil wants in the new QT so we just have to put up with the Window issue until QT gets fixed.

I see Kiwidude beat me again

There are various bug reports on this in Qt such as this one. It still hasn't been fixed (I haven't tried Qt 5). I figured out a workaround (not that filthy one on that bug thread) which will be in the next Sigil build.