Sigil-1.0.0 Released

[KevinH]

I just spent time eyeballing this code and blockingMap is used with QtConcurrent so nothing will be returned until all threads except the main one are reaped/collected.

So the extra sections problem does not appear to be threading caused/related at all to me. So this brings us back to sticking keys I think or key related Qt bugs.

Kevin

Originally Posted by KevinH

This is just a wag on my parts... but multiple threads are used to validate that a split is safe. Typically we need to collect/sync/reap all such threads before returning from the routine that spawns them.

Could extra threads being created to validate a book with many existing chapters somehow be related?

How many files/sections/chapters were in your book when it exhibited this behaviour? One big one being split? Or many already existing?

[Mister L]

Originally Posted by KevinH

This is just a wag on my parts... but multiple threads are used to validate that a split is safe. Typically we need to collect/sync/reap all such threads before returning from the routine that spawns them.

Could extra threads being created to validate a book with many existing chapters somehow be related?

How many files/sections/chapters were in your book when it exhibited this behaviour? One big one being split? Or many already existing?

Both yesterday and today (it was the same book) there were already many existing files, one of which was being split. I had manually renamed most of them to make navigation easier for myself since I hadn't yet generated the toc and when the extra splits occurred I thought that all my manually-entered names had been replaced because suddenly I had 20 Section000N.xhtml instead of descriptive filenames, otherwise I might not have noticed it so quickly.

Originally Posted by KevinH

I just spent time eyeballing this code and blockingMap is used with QtConcurrent so nothing will be returned until all threads except the main one are reaped/collected.

So the extra sections problem does not appear to be threading caused/related at all to me. So this brings us back to sticking keys I think or key related Qt bugs.

Kevin

Could a mouse create a "sticking key" situation ? From time to time my right mouse button seems unresponsive and for example I have to try more than once to rename / delete / whatever a file via the book browser but I am perfectly willing to accept that it's my mouse's fault, I was assuming that anyway for that behaviour because I'm about 85% sure I've noticed it outside of Sigil. Not sure how it would work for the extra splits because that is the left button (which doesn't seem sticky to me, that I've noticed), but if it is technically possible maybe that's the trouble, if no-one else has this problem.

[KevinH]

Okay, I have modified the source code of Sigil to print qDebug() output that shows the keys actually being received in the ShortCut Manager Preferences and it also shows the native scan code, native modifiers, and native virtual key values. I have pushed this to Sigil master.

@DiapDealer, since you can duplicate this issue when using the US International keyboard layout, perhaps you could log the debug output from testing the problem under both the US and US International keyboards so we can compare the output for the same key sequence that does not seem to work.

ps. I have tested this on macOS and it seems to record the modifiers exactly as stated in the QKeyEvent class documentation for macOS so I can not recreate this issue.

KevinH

Originally Posted by Mister L

I have a question about keyboard localisation and keyboard shortcuts... I'm using Sigil with the interface in english but my keyboard is french and my system language is french.

I am trying to set a keyboard shortcut for "Restructure to Sigil norm". I want to use CTRL+* since it seems like an easy to remember and conflict-free choice. But when I type that in the preferences dialogue, Sigil tells me I have typed CTRL+\ and it conflicts with Back. The * on my keyboard is not on the same key as the \ so I thought maybe in this specific case only Sigil does not recognise my keyboard locale, but in regular use it obviously does because if I am writing a regex for instance the S/R dialogue correctly enters the *. I tried switching the interface language to french and relaunching Sigil, this did not work, then I tried looking up an english language keyboard to see where is the asterisk on that one and typing the equivalent keys for * (CTRL+SHIFT+8) but then Sigil said I typed CTRL+SHIFT+\ (in fact to type \ on my keyboard I need to type ALT GR+8).

Now I am just confused...

Is this a bug? Is * forbidden in keyboard shortcuts? Am I doing something wrong?

This is what my keyboard looks like:



Thanks to anyone who can help me...

[KevinH]

We can add some debug code to output each time the routine in invoked. If your key sticks or is on some sort of autorepeat, we should be able to detect that.

I will try to figure out the best place to do that in the source code.

KevinH

Originally Posted by Mister L

Both yesterday and today (it was the same book) there were already many existing files, one of which was being split. I had manually renamed most of them to make navigation easier for myself since I hadn't yet generated the toc and when the extra splits occurred I thought that all my manually-entered names had been replaced because suddenly I had 20 Section000N.xhtml instead of descriptive filenames, otherwise I might not have noticed it so quickly.



Could a mouse create a "sticking key" situation ? From time to time my right mouse button seems unresponsive and for example I have to try more than once to rename / delete / whatever a file via the book browser but I am perfectly willing to accept that it's my mouse's fault, I was assuming that anyway for that behaviour because I'm about 85% sure I've noticed it outside of Sigil. Not sure how it would work for the extra splits because that is the left button (which doesn't seem sticky to me, that I've noticed), but if it is technically possible maybe that's the trouble, if no-one else has this problem.

[KevinH]

@Mister L,

Okay, just pushed some debug code to track how split at cursor is being invoked.

If you are willing to try a debug build, and can use environment variables to create a log file using "SIGIL_DEBUG_LOGFILE" environment variable and repeat it to see if you can get it to record the error and if so send us the log file, please pm DiapDealer and ask?

[Mister L]

Originally Posted by KevinH

@Mister L,

Okay, just pushed some debug code to track how split at cursor is being invoked.

If you are willing to try a debug build, and can use environment variables to create a log file using "SIGIL_DEBUG_LOGFILE" environment variable and repeat it to see if you can get it to record the error and if so send us the log file, please pm DiapDealer and ask?

Yes, no worries, I've used a debug build before. I will pm DiapDealer. Thank you! (Of course, how much do you bet that once I start using the debug version, I never see the bug again... )

[DiapDealer]

Originally Posted by Mister L

then I tried looking up an english language keyboard to see where is the asterisk on that one and typing the equivalent keys for * (CTRL+SHIFT+8) but then Sigil said I typed CTRL+SHIFT+\ (in fact to type \ on my keyboard I need to type ALT GR+8).

I just noticed this last part. By my admittedly meager efforts to decipher Sigil's KeyboardShortcutsWidget code, it appears to that the AltGr modifier is not included in the list of valid modifiers/keys to be used for shortcuts.

Perhaps this is part of the problem.

[KevinH]

The actual Qt code includes that modifier (from qevent.cpp)

Qt::KeyboardModifiers QKeyEvent::modifiers() const
{
    if (key() == Qt::Key_Shift)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::ShiftModifier);
    if (key() == Qt::Key_Control)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::ControlModifier);
    if (key() == Qt::Key_Alt)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::AltModifier);
    if (key() == Qt::Key_Meta)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::MetaModifier);
    if (key() == Qt::Key_AltGr)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::GroupSwitchModifier);
    return QInputEvent::modifiers();
}

But I think the Windows platform code may not enable it?

[KevinH]

That said, the modifiers in the added qdebug will list all valid modifier flags including the altgr if it is used.

[KevinH]

MisterL

would you try using the right Ctrl key instead of the left Ctrl Key when you try to set that shortcut and let me know if it makes a difference?

I found a Qt note that says the Windows keyboard mapper code for some keyboardmaps will interpret a left Ctrl followed by a right Alt (or Menu) key as you using the AltGr key instead.

I was hoping to avoid that by you trying to set the shortcut only with the right Ctrl key andnot the left one to see if that impacts things.

[hobnail]

Originally Posted by KevinH

The actual Qt code includes that modifier (from qevent.cpp)

Qt::KeyboardModifiers QKeyEvent::modifiers() const
{
    if (key() == Qt::Key_Shift)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::ShiftModifier);
    if (key() == Qt::Key_Control)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::ControlModifier);
    if (key() == Qt::Key_Alt)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::AltModifier);
    if (key() == Qt::Key_Meta)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::MetaModifier);
    if (key() == Qt::Key_AltGr)
        return Qt::KeyboardModifiers(QInputEvent::modifiers()^Qt::GroupSwitchModifier);
    return QInputEvent::modifiers();
}

But I think the Windows platform code may not enable it?

Could key() be returning different values for subsequent if statements? What about doing

k = key();
if (k == Qt::Key_Shift)
etc.

[KevinH]

no it is a property of the const event

[Senior47]

I see that several people are experiencing the same error.
Well, it doesn't appear to be a sticky key, the same behavior occurs using the "Edit, Split At Cursor" menu.

Looks like the error is related to "Tabs" closing.

Everything seems to work fine until you close one or more tabs, the next time you use "Split At Cursor" you get this "error".
Closing two tabs gives you 2 "blank" sections, 5 tabs get 5.

Poorly explained, maybe my screenshot is better?

Svein

[DiapDealer]

Two is several, now?

Please make sure to not include inline images with either dimension more than 600px. It's against forum rules. Attach them to the post (and optionally inline a thumbnail). I'll fix this one for you.

[DiapDealer]

But I can finally duplicate it. In a few simpler steps. Thanks for sticking to it until you found something reproduceable!

1) make sure Sigil is closed
2) launch Sigil (empty epub)
3) click File->New->Default|Epub2|Epub33 (doesn't matter what kind of new epub)
4) place cursor before the p tag in Code View
5) split using the shortcut or Edit->Split at Cursor

The bottom line is that the problem doesn't manifest until some tabs get closed/destroyed. Seems to get worse with each tab that gets closed (or each new epub that's created without closing Sigil and relaunching).

@Kevin: I don't know that it's necessarily another issue associated with the Create New Epub2|3 feature, because I can get it to happen without using it. Closing some open tabs in general seems to trigger it. Until you close a tab, splitting seems to work as expected.

Reproduceable on Windows 10 and Linux.