File Type Icon Disappearing in Book Browser

[slowsmile]

I'm not sure whether this has already been reported, but I've recently noticed that whenever I physically move an .xhtml file using drag and drop in the Text directory of the Book Browser in Sigil, the associated file type icon(Chrome Browser) completely disappears and the moved file ends up misaligned with no icon. All the other .xhtml files in the Book Browser display the correct file type icon. This isn't really a big deal but I just thought that I'ld mention it.

I'm using Windows 8 with Sigil 0.9.7

[theducks]

It reappears when you 'save' (W10pro aniv)

[DiapDealer]

Yes, it's been noticed and reported. Seems to be an innocuous Qt quirk that has crept in along the way. It's not new to the latest version of Sigil. There's lots of things that will makes the Book Browser icons disappear/come back. Haven't had time to see if there's anything we can do to work around the issue or not.

[BetterRed]

OT a bit, this is on Windows 10 1511.

I have the Book Browser and the TOC panels docked as Tabs on the left edge. Of late, perhaps with the advent of Sigil 0.9.7, the TOC always takes priority when I start Sigil, whereas I'm sure the Book Browser (left most) took precedence at an earlier time.

So I now have to click the Book Browser tab to see the files, or toggle the BB off and on with Ctrl+Shift+B. I looked in the in sigil.ini for something to edit - but couldn't see anything likely. I tried reinstalling Sigil, I tried creating a fresh sigil-ebook in Appdata\Local and reconfiguring, I tried un-docking and re-docking the BB and TOC - all to no avail.

Anyone know of a way to fix this, other than removing the TOC from the left dock?




Regarding the disappearing icons - maybe provide an option to suppress them. IMO if the full file name is displayed, which it it is, the icons are akin to t**s on fish

BR

[Doitsu]

Originally Posted by BetterRed

Anyone know of a way to fix this, other than removing the TOC from the left dock?

Actually, I didn't know that you can have two tabs left of the Code View window.

If you want to restore the default window positions:

1. Press ALT+F1 to hide the Book Browser.
2. Drag & drop the TOC Window right of the Code View window.
3. Press ALT+F1 to unhide the Book Browser window.

Alternatively, close Sigil, edit sigil.ini and delete the toolbars entry under [mainwindow].

[MickiTee]

Originally Posted by BetterRed

I have the Book Browser and the TOC panels docked as Tabs on the left edge. Of late, perhaps with the advent of Sigil 0.9.7, the TOC always takes priority when I start Sigil, whereas I'm sure the Book Browser (left most) took precedence at an earlier time.

So I now have to click the Book Browser tab to see the files, or toggle the BB off and on with Ctrl+Shift+B. I looked in the in sigil.ini for something to edit - but couldn't see anything likely. I tried reinstalling Sigil, I tried creating a fresh sigil-ebook in Appdata\Local and reconfiguring, I tried un-docking and re-docking the BB and TOC - all to no avail.

Anyone know of a way to fix this, other than removing the TOC from the left dock? BR

I have three tabs (your two plus Clips) docked and Sigil has always defaulted to the Clips tab for as long as I've had this set-up - from V0.7.x onwards on a machine running Windows 7 32-bit. I've learnt to live with it as rearranging the tabs makes no difference.

[BetterRed]

Originally Posted by Doitsu

Actually, I didn't know that you can have two tabs left of the Code View window.

If you want to restore the default window positions:

1. Press ALT+F1 to hide the Book Browser.
2. Drag & drop the TOC Window right of the Code View window.
3. Press ALT+F1 to unhide the Book Browser window.

Alternatively, close Sigil, edit sigil.ini and delete the toolbars entry under [mainwindow].

@Doitsu - thanks, but didn't I effectively do that by reinstalling and recreating a fresh config folder, After configuring to my taste (removing toolbars, setting fonts and colours, changing kb shorts etc) and docking the panels as I want them, I was back in the same boat.

BTW I always use F2 to do line item edits, so I always remove or disable the F1 key - permanently; if I'm editing a file name or a value in metadata edit a the last thing I need is to leap off to a help website or even look at a local CHM. So I have the kb short for show/hide BB toggle set to Shift+Ctrl+B.

In the calibre editor which I assume uses the same Qt docking feature as Sigil, I have configured the Files, Live CSS, and TOC panels to dock as tabs on the left edge in that LTR order. When it opens a file, the Files tab (left most) is shown. I don't recall doing anything specific to make that happen. Although I do recall it was a PITA to get the three tabs to show in that order, so I'm loathe to mess with it.

IMO the docking tabs badly need a context menu and kb shorts (move tab left/right, show next/prev tab, remove tab etc), I'm guessing Qt doesn't provide the hooks - like there's no tool tip on action items Ψ².

@MikiTee - hmmm, I'm almost certain the BB panel was shown when I opened an epub in the not too far distant past. I avoid using the mouse so I tend to notice this sort of thing. But I could mistaken. It would interesting to know on what basis Sigil (or Qt) decides which tab takes priority.

To overcome the 'problem' I removed the TOC panel. Alt+V followed by a couple of up-arrows is not that hard :lol:

BR

[DiapDealer]

Originally Posted by BetterRed

@[B]@MikiTee - hmmm, I'm almost certain the BB panel was shown when I opened an epub in the not too far distant past. I avoid using the mouse so I tend to notice this sort of thing. But I could mistaken. It would interesting to know on what basis Sigil (or Qt) decides which tab takes priority.

I believe it's Qt that decides. At least I can't find find any Sigil code that would prefer one widget over another whenever they're in a tabbed configuration. In a perfect world, the saveState()/restoreState() calls would remember which one was "on top" when Sigil was closed, and restore them to that state when Sigil was reopened. But it doesn't seem to work that way.

[kovidgoyal]

save/restore does cause the order + current tab to be restored. As for getting them in a particular order, IIRC the way to do it is to add them to the panel in reverse order, that is, the last added tab will be the first one in the tab bar.

[theducks]

Originally Posted by Doitsu

Actually, I didn't know that you can have two tabs left of the Code View window.

If you want to restore the default window positions:

1. Press ALT+F1 to hide the Book Browser.
2. Drag & drop the TOC Window right of the Code View window.
3. Press ALT+F1 to unhide the Book Browser window.

Alternatively, close Sigil, edit sigil.ini and delete the toolbars entry under [mainwindow].

Yep!
It takes some fussing, but it does tab. Same with Calibre

[BetterRed]

Now I've given TOC View a rememberable (memorable ?) keyboard shortcut (Ctrl+Shift+T) I don't need to have the TOC permanently parked in a dock tab.

Originally Posted by kovidgoyal

save/restore does cause the order + current tab to be restored. As for getting them in a particular order, IIRC the way to do it is to add them to the panel in reverse order, that is, the last added tab will be the first one in the tab bar.

Yes that controls the order in which they appear, but it doesn't seem to affect which one is opened when Sigil (or the calibre editor) starts.

No matter what I do in Sigil regarding the order of two tabs, the TOC is always opened when Sigil starts, and if I have Clips in the same dock, it's always opened when Sigil starts - irrespective of the order of the three tabs. Which is what MickiTee reports.

Conversely no matter what I do in the calibre editor with respect to the order of the three tabs (Files, Live CSS, TOC) the Files Browser is always opened when the editor starts. Which makes sense because the calibre editor starts with no files open.

Is calibre's behaviour a fortuitous fluke, and Sigil's luckless misfortune? Or are both 'by design'? Starting with the TOC might make sense if one did most of one's editing in Book View?

BR

[DiapDealer]

Originally Posted by kovidgoyal

save/restore does cause the order + current tab to be restored.

i would think that should be the case, but one dock widget always seems to be the "default" after restoreState is called. -- no matter which tabbed QDockWidget was current when saveState was called. Only the order (and the tabbed state itself, of course) seems to be being saved and/or restored. I'll keep looking for Sigil Code that might be in play after restoreState (or before saveState), but I sure haven't found any yet. Keep in mind that any tabbed dockwidget configurations are made by the user. Sigil doesn't tabify any dockwidgets programmatically.

Originally Posted by kovidgoyal

As for getting them in a particular order, IIRC the way to do it is to add them to the panel in reverse order, that is, the last added tab will be the first one in the tab bar.

Qt5.6+ allows the user to drag the tabs into desired order with the mouse, as well.

[kovidgoyal]

@BR -- IIRC calibre treats a few dock widgets specially, the File Browser being one, since it is cetral to the operation of the editor. Personally, I keep docked tabs on the right side, where the one that was the current tab when the editor was closed is always the one that is the current tab when it is restarted, at least for me.

[kovidgoyal]

Originally Posted by DiapDealer

i would think that should be the case, but one dock widget always seems to be the "default" after restoreState is called. -- no matter which tabbed QDockWidget was current when saveState was called. Only the order (and the tabbed state itself, of course) seems to be being saved and/or restored. I'll keep looking for Sigil Code that might be in play after restoreState (or before saveState), but I sure haven't found any yet. Keep in mind that any tabbed dockwidget configurations are made by the user. Sigil doesn't tabify any dockwidgets programmatically.

Haven't seen that myself -- one thing that comes to mind is if Sigil calls show/setVisible on some tabs explicitly, that might mess with the order.

Qt5.6+ allows the user to drag the tabs into desired order with the mouse, as well.

That's good, though calibre will only move to Qt 5.6 for calibre 3.0

[DiapDealer]

Originally Posted by kovidgoyal

Haven't seen that myself -- one thing that comes to mind is if Sigil calls show/setVisible on some tabs explicitly, that might mess with the order.

That's a possibility. There's a lot of residual "workaround" code still in place for dealing with maximized window-state issues in Qt4.8. I've no idea if they're necessary or even relevant anymore.

Of the four Sigil dockwidgets that are tabbable, there definitely seems to be a very specific "pecking order" they honor whenever user-tabified dockwidgets are restored. That pecking order should probably be a pretty-good clue as to what's going on.

Thanks for the verification that "current tab" SHOULD be being restored, though. I couldn't find any hard-and-fast evidence in the documentation that that was indeed the case (though it makes sense that it should be). Knowing it should work is half the battle most times.