11-16-2023, 05:20 PM | #31 |
null operator (he/him)
Posts: 20,761
Karma: 27405072
Join Date: Mar 2012
Location: Sydney Australia
Device: none
|
|
11-17-2023, 02:08 AM | #32 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
Sure. They are simply helpful, although of course the user usually knows what shortcut they have called up
|
Advert | |
|
11-18-2023, 01:55 PM | #33 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
I have noticed that if sub-windows are merged (e.g. TOC + Book Browser or TOC + Clips) then the focus changes, but the called window is not switched to the foreground.
You can see this clearly in the attached screenshot. The Book Browser is still visible, despite the change of focus to TOC. |
11-18-2023, 03:13 PM | #34 |
Grand Sorcerer
Posts: 27,669
Karma: 195159104
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Tabbified qdockwidgets have always behaved with a mind of their own.
|
11-18-2023, 03:20 PM | #35 |
Sigil Developer
Posts: 7,851
Karma: 5449552
Join Date: Nov 2009
Device: many
|
Yes I am seeing the same thing on macOS. Not sure how to detect if QDockWidget is tabbified and not the front tab.
Will try to see if there is any solution. |
Advert | |
|
11-18-2023, 03:41 PM | #36 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
I did a trial and raise() seems sufficient.
It doesn't need to be added to the Code View, as no other widgets can be added to this window. Code:
void MainWindow::FocusOnBookBrowser() { FocusOn(m_BookBrowser); m_BookBrowser->FocusOnBookBrowser(); m_BookBrowser->raise(); ShowMessageOnStatusBar(tr("Focus changed to BookBrowser window.")); } void MainWindow::FocusOnPreview() { FocusOn(m_PreviewWindow); m_PreviewWindow->SetFocusOnPreview(); m_PreviewWindow->raise(); ShowMessageOnStatusBar(tr("Focus changed to Preview window.")); } void MainWindow::FocusOnTOC() { FocusOn(m_TableOfContents); m_TableOfContents->SetFocusOnTOC(); m_TableOfContents->raise(); ShowMessageOnStatusBar(tr("Focus changed to Table Of Contents window.")); } void MainWindow::FocusOnClips() { FocusOn(m_Clips); m_Clips->SetFocusOnClips(); m_Clips->raise(); ShowMessageOnStatusBar(tr("Focus changed to Clips window.")); } |
11-18-2023, 03:46 PM | #37 |
Sigil Developer
Posts: 7,851
Karma: 5449552
Join Date: Nov 2009
Device: many
|
Sounds good. I am away from my dev machine. Please create a PR and I will merge it, or I will make that change on Monday when I am back home.
|
11-18-2023, 04:15 PM | #38 |
Grand Sorcerer
Posts: 27,669
Karma: 195159104
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
There's an .isTabified property I think. But if raise() is not going to trigger anything unnecessary, checking the property before doing so is probably overkill.
|
11-18-2023, 04:57 PM | #39 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
I checked via Debug that the widget can be checked for visibility before raise().
When the widget is in the foreground then raise() will not be called. So an extra test shouldn't hurt, here an example: Code:
void MainWindow::FocusOnTOC() { FocusOn(m_TableOfContents); m_TableOfContents->SetFocusOnTOC(); DBG qDebug() << "Focus"; if (m_TableOfContents->visibleRegion().isEmpty()) { DBG qDebug() << "Here raise"; m_TableOfContents->raise(); } ShowMessageOnStatusBar(tr("Focus changed to Table Of Contents window.")); } |
11-19-2023, 06:04 AM | #40 |
Enthusiast
Posts: 35
Karma: 10
Join Date: Aug 2018
Device: kobo Nia
|
just one more thing... (not Columbo 8^)
Hi,
one more niggling detail: When the Find dialog has found a match and displays it in the Code view, oftentimes i want to focus the match and edit there. For example, in building an ebook, i collected a bunch of web pages, named them s\d+.xhtml (numbered), and have a list of original URLs as TOC (keeping a copy as Refernce page), which i then replace (via regex) with s1.xhtml. Next, i scan for "s1 and want to edit the matches to change the numbers. It would be nice if a found match would focus there. But it's no big thing, i can Focus the Code view, and it's just one shortcut more to type. Last edited by recook; 11-19-2023 at 11:39 AM. Reason: expanded |
11-19-2023, 07:52 AM | #41 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
I don't know if I'm understanding you correctly, but you want to search for something, and after the search the focus is supposed to remain in the Find box?
If so then your request is the opposite of the approach in Sigil. Find&Replace should not steal focus. [link] If you want to edit your search then you'd better get used to that extra Ctrl+F though. |
11-20-2023, 06:35 AM | #42 | |
Enthusiast
Posts: 35
Karma: 10
Join Date: Aug 2018
Device: kobo Nia
|
Hi,
indeed not, i'm sorry. Once more, unto the breach: I type ^F, then (in my example) the three characters "s1 into the find text field, then either click Find or type ^F again to find. When a match is found, i can (with the new Focus shortcuts - thanks @DiapDealer!) type the new shortcut to focus the Codeview to edit the match. If Find would directly focus Codeview when a match is found, that last focus action wouldn't be necessary. Actually, i never even got the Idea to Quote:
Last edited by recook; 11-20-2023 at 06:50 AM. Reason: clarify |
|
11-20-2023, 07:02 AM | #43 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
Wait, wait...
You mean to say that in version 2.0.2, after searching for something, the focus does not jump to Code View and remains in F&R? Ctrl-F in F&R does not result in a search, Find button should jump to Code View. |
11-20-2023, 09:22 AM | #44 | |
Sigil Developer
Posts: 7,851
Karma: 5449552
Join Date: Nov 2009
Device: many
|
Well it seems with multiple main windows on macOS, the visibleRegion().isEmpty() test failed sometimes and so no raise was done but needed.
I think the safest way to handle this is to use raise() called immediately after FocusOn call and before the specific internal subwidget is given focus. This should not hurt anything and works on macOS as well. I also added a nullptr check for each to make sure the QDockWidget in question has not been deleted yet for safety in case someone deletes a main Window and shortcut keys or key events are waiting to be flushed out. This is more of a concern on macOS with its multiple main windows but is safer for everyone. I have pushed this master. If you get a chance please make sure I have not hurt anything on Windows. It should all be okay but just to make sure. I think with this change, we should consider this new feature as complete. Glad people find it useful. KevinH Quote:
|
|
11-20-2023, 10:22 AM | #45 |
Guru
Posts: 711
Karma: 2180740
Join Date: Jan 2017
Location: Poland
Device: Various
|
I have built a new Sigil, I will check the focus switching during normal use of the application.
In short tests on Windows 10 Pro, everything looks good. Thank you! |
Tags |
book view, code view, focus, keyboard shortcuts, preview |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Book-details panels and keyboard focus | BetterRed | Library Management | 3 | 05-12-2023 03:22 AM |
Keyboard Shortcuts request | David Kudler | Sigil | 2 | 08-07-2020 06:09 PM |
feature request - Shortcuts for Plugins | Camelot | Sigil | 12 | 12-28-2015 04:50 AM |
keyboard shortcuts | vikischeldrup | Library Management | 4 | 08-23-2013 04:55 AM |
feature request - switch templates | kgn | Calibre | 8 | 07-23-2010 09:17 AM |