Sigil-0.9.10 Released

[RbnJrg]

Originally Posted by DiapDealer

Is there a particular reason you've chosen to install the runtime yourself, rather than just letting it be distributed by the programs that need/supply it?

I installed the runtime because I had installed it and Sigil 0.9.10 overwrote it and with that runtime Sigil didn't work. So, I unistalled Sigil, I uninstalled the runtime, I installed again the spanish runtime, I reinstall Sigil and when it wanted to install the "new" runtime, I aborted it and this time, Sigil worked.

I think what you said in your last post is the best option; to let the user to allow Sigil to install (or not) the newest runtime.

[DiapDealer]

Originally Posted by RbnJrg

I installed the runtime because I had installed it and Sigil 0.9.10 overwrote it and with that runtime Sigil didn't work. So, I unistalled Sigil, I uninstalled the runtime, I installed again the spanish runtime, I reinstall Sigil and when it wanted to install the "new" runtime, I aborted it and this time, Sigil worked.

I think what you said in your last post is the best option; to let the user to allow Sigil to install (or not) the newest runtime.

My question was why you had installed the runtime yourself (regardless of the language) in the first place. It's not typically something an end-user needs to worry about very often. Had you uninstalled both Sigil and the Spanish runtime (again: whatever a "Spanish runtime" even is) and reinstalled Sigil, it would have run just fine with it's own included runtime. Even on Spanish computers.

But yes. An option to not install it is probably the best solution, here

[RbnJrg]

Originally Posted by DiapDealer

My question was why you had installed the runtime yourself (regardless of the language) in the first place.

Ahh, I understand you now; I had this runtime installed because others programs I have, they had installed it, like Sigil does. But I don't know why Sigil with its "own" runtime doesn't work in my system.

[DiapDealer]

Originally Posted by RbnJrg

But I don't know why Sigil with its "own" runtime doesn't work in my system.

It would work just fine _IF_ the other runtime wasn't already installed. The problem isn't the version of the runtime Sigil that tries to install itself. The problem is caused by Sigil trying to install its version in addition to (or over top of) the one you have installed. That is what shouldn't be happening. I'm just lamenting the fact that Windows makes it so difficult to manage this situation from a deployment standpoint. Having to check for different versions of different language editions of the same runtime just isn't feasible. Especially when language-specific versions of a C++ runtime (whose version numbers clearly don't match their counterparts') doesn't even make a little bit of sense to me.

Alas.

[JustinThought]

Has anyone else had any issues with search? I installed 0.9.10 on my Windows 7 (64bit) system, and checked the current epub. FlightCrew indicated there was a .jpg file that was reachable, but not in the manifest (which was true--I hadn't loaded it yet), so I searched for it, all html files, both normal and regex, and it didn't find it. On brief experimentation, it looks as if Sigil can find something in the current file or a nearby (don't know how nearby, didn't experiment that much), but distant files don't seem to be found.

I did take it into my desktop, where the previous version is still hanging out, and it found the reference immediately.

Anyone else want to experiment here? Or is it--as has happened before--something related to my environment?

Edit: a little later: I'm back at 0.9.10, and I'm unable to duplicate the issue. Nothing has changed in the environment. I'm putting this down as just a fluke. The gods of computerdom were frowning on me at that moment.

[BetterRed]

Originally Posted by DiapDealer

Not really sure, to be honest. My gut says no (no there shouldn't be any issues), but Windows is so weird about how memory-resident functions of dlls work/persist, that I wouldn't swear to it. The sigil-specific dlls (python35 gumbo and hunspell) shouldn't cause any issues. Because 1) they've not been altered between 0.9.9 and 0.9.10; 2) they were all built with VS2015; and 3) Windows first priority for library search paths is the current directory (so all of those libraries are packaged adjacent to the Sigil executable for that exact purpose). The environment for the python-based plugins (run in a separately executed process) is tightly-controlled and should pose no problems.

Just remember they'll share the same preferences unless you launch one version of Sigil with the SIGIL_PREFS_DIR set to somewhere else.

I'll summon up the courage to give it a go, I'll let you know the results.

Your discussion with Ruben has echoes of the problems I had with Sigil and the C++ libraries in the distant past - which is what prompted my question.

At the time I had dozens of "Microsoft Visual C++ 2008 Redistributable - XXXXXXXX" installed, I'm now down to a mere eight - only one of which is 2015. Not sure what I did, or more probably what MS did, to reduce the number, that happened when I was still using Win7.

BR

[DiapDealer]

Originally Posted by JustinThought

Edit: a little later: I'm back at 0.9.10, and I'm unable to duplicate the issue. Nothing has changed in the environment. I'm putting this down as just a fluke. The gods of computerdom were frowning on me at that moment.

I was just about to say that there were no changes that I know of that should have affected S&R in this release.

[DNSB]

Originally Posted by JustinThought

Edit: a little later: I'm back at 0.9.10, and I'm unable to duplicate the issue. Nothing has changed in the environment. I'm putting this down as just a fluke. The gods of computerdom were frowning on me at that moment.

We don't believe in miracles, we just depend on them.

[odamizu]

DiapDealer and KevinH for all your work on Sigil.

I LOVE LOVE LOVE the custom icons for plugins. Yay! And thank you, Doitsu, for pointing out how to add your own custom icons.

Originally Posted by KevinH

I will try to bring that back for the next release if there is someway to separate a mousepress event in a link area from a mousepress event in a non-link area. Webkit will detect link related clicks (with any and all modifier keys) and send a signal with a URL but the mousepress event itself does not provide info to know if a scroll update is wanted or the beginning of a link click.

Short of that we will add a preference setting for the next release allowing the user to set how they want clicks in Preview to be treated if needed.

Thank you! I prefer having clicks in Preview sync with CodeView the way clicking in CodeView syncs with Preview. Having a preference setting to choose how clicks in Preview are treated would be fabulous.

[JustinThought]

Originally Posted by DNSB

We don't believe in miracles, we just depend on them.

My nephew, who is a much more capable computer "geek" than I am, assures me that what makes computers do their thing is something called "FM". Now, this being a family forum, I'm not going to go into too much detail on his definition, but I can tell you that the second word is "Magic."

A while back, I confused DiapDealer and Kevin when I reported a little inconvenience when moving files around in a book with many chapters--when you dragged it to its new home and released it, the focus of the Book Browser would shift to the beginning (or sometimes the end--depending on that FM), and in order to shift the focus back to the file, I would have to re-highlight that tab in the code window. I tried it today with 0.9.10, and that still occurs. The focus in the Book Browser window "pops" to the top, not the new location of the file.

As before, it's not a huge issue, just a slight inconvenience. I would place the solving of this one wayyyyyy down at the bottom of the list.

Really like the new release, though. I haven't started customizing my plugin icons yet, because then I'd get all obsessive about that. I'll save that for tomorrow. Thanks, guys!

[exaltedwombat]

Originally Posted by exaltedwombat

And that is why we love Sigil! Thank you.

This is bad. I'm going through a new conversion from PDF. Quite clean, but the usual need for putting in chapter breaks, cleaning up the rogue paragraph feeds...

I NEED a click in Preview to locate in Code View. Please restore this as a matter of urgency!

Hope I can revert to the previous Sigil version in the meanwhile... Otherwise this job is going to be impossible.

<later>

Phew! Yes I can. Panic over for now...

[DiapDealer]

I'm glad the panic is over.

For others...

We will restore the feature. But there is no urgency. It's quite trivial to downgrade to Sigil 0.9.9 in the meantime. Just uninstall Sigil and install the older version to downgrade. It's that simple.

[exaltedwombat]

Originally Posted by DiapDealer

I'm glad the panic is over.

For others...

We will restore the feature. But there is no urgency. It's quite trivial to downgrade to Sigil 0.9.9 in the meantime. Just uninstall Sigil and install the older version to downgrade. It's that simple.

Thanks again!

Safely back on 0.9.9.

Interesting that different people use Sigil in different ways. It's just me who found that change a showstopper?

[Notjohn]

It is certainly true that it would be nice to have Code View keep level with Preview, but I think it's even nicer that as I page down through Code View, the Preview panel now moves along with it -- I needn't click on a line in Code View! (It also happens when I page UP.)

I may be wrong, but I don't think previous version of Sigil did that without being asked.

(Windows 7 Pro, 32-bit.)

[DiapDealer]

Originally Posted by exaltedwombat

It's just me who found that change a showstopper?

No. I think there's many who rely heavily upon it. Some commented on Github; some here. I think most here, though, saw that we were going to offer users a choice--at the very least--in the next release, and just downgraded if they couldn't live without it in the meanwhile.

We're still testing, but signs are looking very good that we might be able to accommodate BOTH link-following and Preview->Code View synchronization (with no user preference decision to be made) in the next version. No promises yet, though.